I have a plan to install my application which is compiled using RAD2010 in Vista 32 bit dev. environment, in a win 2008 server 64 bit.
I use Firebird 2.0 (32 bit) as database server.
Is there any issue? Or it should run without any problem?
No problem for this.
If you can use Firebird 2.1 (a version for 64bit server can be use).
Just take the fbclient.dll (32 bit version)
I see no reason why it shouldn't work, 32 bit processes and services work well under x64. If you need lots of memory for you application you can set the LARGE_ADDRESS_AWARE flag which gives your application access to 4GB of address space instead of 2 GB. If you want that you need to add a line containing {$SetPEFlags $20} to the .dpr file.
We have encountered 2 problems with Windows 2008 Server, but it does not seem they should impact you too much:
Critical Sections now come with a debug baggage that is cached and not freed when they are released. If you create lots of them, the memory footprint of your application will be much bigger. Can happen when using Interfaces or Threads heavily. see is-the-memory-not-reclaimed-for-delphi-apps-running-on-windows-server-2008-sp1 and critical-sections-leaking-memory-on-vista-win2008.
When using ADO, there is a memory leak (in MS stack) when passing the ConnectionString. If you close the connections and open them a lot passing the ConnectionString you end up eating all the memory after a while.
The only problem is if your application is library that needs to be loaded into a 64bit Process.
Examples:
Shell Extensions
ISAPI applications
Related
I have one application which is built using Delphi 5.0 and works fine without any issues. But when running large report my application needs more than 2 Gb memory. After doing analysis found that using Compiler directive SETPEFlags we can increase 32 bit application memory upto 4 GB.
I am trying to set in my program in Delphi 5.0 but getting error "Invalid Compiler Directive". Can somebody suggest any way to resolve without rebuilding application in other version. Or what version those got added to Delphi?
Thanks in advance.
You can't get the tools in Delphi 5 to mark your application as Large Address Aware ({$SetPEFlags} was added in Delphi 6). You need to add that PE flag as a post build setting. The usual way to set that flag is to use Microsoft's editbin tool.
Once you do this, your program will stop working as soon as you allocate memory beyond the 2GB boundary. That's because the default Borland memory manager does not support large addresses. You will need to replace it with FastMM or other LAA-capable memory manager. Or you can write your own replacement memory manager using, for instance, HeapAlloc(), if you wish.
Situation:
I developed a DelphiXE5 ISAPI Webbroker application on a VMWare workstation under WIndows 7 Pro 64Bit. Testing on that platform with the code compiled as 32bit (default for DelphiXE5) was successful. The program consacts Stamps.com via HTTPS and uses the Stamps.com SOAP web application to purchase postage and create a mailing label with a valid postage stamp (indicium).
The mailing label is created as a PDF on a Stamps server and they send me back a URL which I then use to fetch the PDF and save it in my local SQL Server database. This fetch is done using INDY 10.6.0.5040 (per Remy at Indy). As part of that fetch, the INDY ssl component has to load and use the OpenSSL libraries. These load OK in the test environment.
I then moved the program (compiled as 32bit) to the Windows 64bit 2003 R2 server. This server is a virtual server running under VMWare. I am sure that the actual hardware is truly 64 bit. The OpenSSL libraries will not load on that server. I have tried the most current 32 bit libraries and the most current 64 bit libraries. Same result ... not loading. I tried the ones that load successfully in test .. they failed. Using the Indy WhichFailedToLoad() function shows "failed to load libeay32.dll". Funny thing is , I get the same message with the 64bit libraries. The libraries, even though 32 vs 64 bit, have the same name, so i get the same message. Now, my specific questions are ....
could there be a default area that the libraries load from and my placing them in the same directory as my program dll is not changing anything at all ?? Indy is going the default first and if they exist, that's the ones it is using. If so, does anyone know where that might be. I have tried to trace through the INDY code to see what was hapening but it jumps into assembler and I'm not a ms assembler programmer. I know IBM mainframe assembler in my sleep but MS seems uside down and backwards to me :-)
For Delphi experts out there.... SHould the program really be compiled as a 64 bit application and put in production and then use the 64bit libraries? In the test environment I'm running on 64bit hardware, 64bit host, 64bit guest on which the 32bit compile takes place. The 32 bit libraries work there and it seems that it should work in production on W2003 Server as that is identitical .. except for the OS version.
Could it be permissions problem with IIS 8.5 that wont let my dll read or load the OpenSSL libraries ? If so, any hints as to what ?
I have the DLL in the scripts directory along with libraries.
Who ever figures this out can get a job as my backup :-) ... really !
If your program is 32bit, the dll it uses have to be compiled in 32bit.
As for the location of the OpenSSL dlls, in my case, on a Win2012 R2 server, I put them in C:\Windows\SysWow64\inetsrv.
We have an Delphi application that has a built in com object. When compiled in Delphi XE3 (Windows 8) we can't reference it from Visual Studio C#. However, an older version that was compiled in Delphi 2010 (Windows 7) works as expected.
The com object registers without errors and i can access it by using VBA script in Excel. Has anyone come accross something like this?
The most likely explanation is a bitness mismatch. I'm assuming that the COM server is 32 bit since you have been compiling it in Delphi 2010.
Suppose that your COM server is an in-proc server. Then I guess that your failing host is a 64 bit application. If so then you need to make the bitness match. Most probably by switching your host to be 32 bit by targeting x86.
If the COM server is out-of-proc then the issue is with registration rather than executable bitness matching. It will be registered in the 32 bit registry view, but your 64 bit host is looking in the 64 bit view. This would explain why your 32 bit Excel VBA code can find it. You need to register the server in both 32 and 64 bit registry views. Or switch the host to 32 bit.
Over the past 15 years or so I've written all the software that runs my medical practice in Delphi 5.
Last week my disk became unbootable/unrecoverable. I have my original D5p disk and all the components backed up but I want to migrate to Windows7. I don't care if my delphi apps look like vista/7; I just want to be able to install it and code on the machine again for maintenance purposes.
are there any tricks to install D5 so it works in W7?
is using a virtual machine really the only/best way? if so, which is suggested?
Thanks in advance.
Larry
LKohnMD#msn.com
I don't know if this helps, but I run Delphi 7 on 64 bit Windows 7 with no problem.
There are some special steps to installing it, but after that, it works fine.
Check out this site for the details: http://www.drbob42.com/examines/examin84.htm
Although I use VMs for other things, running Delphi inside a VM IMO is a nuisance. So it'll be worth your trying the above. On the other hand, I know developers who swear by VMs for this since they can get such great backup snapshots, as noted by others.
I'm not an expert in the Delphi field any more, but I'm pretty sure you're not going to get D5 running on Windows 7 smoothly. Even if you get it running as such, it's going to give you trouble in the details.
But Windows 7's built-in XP virtual machine is a joy to use, and integrates seamlessly (i.e. you can even have Delphi and your old apps in Windows 7's start menu). I'd say the virtual machine is really the way to go. It's called Windows XP mode and can be downloaded here at no extra cost. You just need Windows 7 professional or better, it won't work on a Home edition.
We do commercial software development using Delphi 2009 in a Windows XP Virtual PC, hosted on Windows 7. Until last year, we were using Delphi 7 on an XP virtual machine on Vista. Both are excellent development platforms.
As far as I can see, there are no downsides to this setup. Under Windows 7, the Virtual XP machine integrates right into the desktop using XP mode. Backups are easy, since the VHD file (Virtual Hard Disk) is typically less than 16 GB. There have been absolutely no issues with stability. And although performance within the virtual machine is somewhat slower than on a native machine, the speed difference is not significant.
My opinion is that this is the best solution, and we have been using it successfully for years. If you have any questions about it, just let me know.
I got tired of having to reinstall all my Delphi components whenever I had to setup my machine from scratch/install a new operating system/move to a new laptop, so when I installed Windows Server 2008 (32-bit), I installed Delphi 5 in a virtual machine.
Because of that, when I recently moved to Windows 7, 64-bit, I could use the same virtual machine, no new setup required!
Granted, it is a bit slower, but, hey, this was meant to run on computers a lot slower than they are today.
It's a win/win all the way...
Two people at work are now running Delphi 5 on Windows 7 64-bit.
There is a problem with some Jedi files, that rely on a particular define (WINDOWS i think), that isn't true in 64-bit environment. In the end the Jedi files are not useing Windows.pas. Code then fails to compile when it can't find declarations such as DWORD.
Also, there is a bug in Delphi 5 compiled code, that is only exposed on 64-bit versions of Windows. If you have Overflow Checking turned on, and anything calls SendMessage, the compiled Delphi code is checking that the BOOL value is not greater than $FFFF.
This is wrong, since BOOL is declared by Win32, Microsoft, and Delphi 5, to be a 32-bit boolean value; in x64 it returns $FFFFFFFF as the non-zero value. It works on 32-bit Windows because Microsoft has to maintain compatibility with 16-bit applications; where BOOL was only 16-bits, returning $0000FFFF. 64-bit versions of Windows are unable to run 16-bit applications (this is because a 64-bit CPU running in 64-bit mode does not support running 16-bit instructions)
In other words: turn off Overflow Checks
If you have the option of restoring the original system to a working state, I recommend doing that, and the use the "VMWare vCenter Converter Standalone Client" to make a VM of your current system. Then install VMWare on the new PC when it gets here. Now you can simply bring that up under your new PC, and you've got your trusty old PC ready to roll, any time you need it.
You can do it. More over you can even deploy lower versions too.
I am running Delphi 4 on windows7 32 bit, now I tried to deploy to win 7 b4 bit.
So far the compile, building works, I can run my app outside ide.
Inside ide, I could not register correctly bordbk40.dllm this is why app is not starting from ide.
Database Desktop is also not working, saying unkown compatibility issues.
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!