My developer machine is a Windows 7 64bit and have some programs on 32 an others on 64 bits
since the upgrade of the 3.70FC3 and 3.70TC3, I'm having problems compiling with VisualStudio 2010 sp1.
maybe there is some configuration that I need to do to change 64 to 32 bit. Or maybe is not supported to have both csdk
If it is feasible, you select which is in use by setting $INFORMIXDIR (oops; I mean %INFORMIXDIR%) to the correct directory and any other related changes (the correct bin subdirectory added to %PATH%, etc).
If there isn't an easy way to switch such variables, then it may not be feasible; I avoid working on Windows so I can't report of my own experience. Classically, it was certainly expected that you would choose one version and stick with it. On Unix, it has been possible to have both, but there isn't the registry to complicate things.
Related
What happens:
create delphi 32 bit application to open up a ms access database, the newer accdb one, created with access 2013 32 bit version. Using TADOConnection and dbgo. Works great.
Change to 64 bit platform, as soon as I try opening up a table at runtime, I get the "provider cannot be found error". Although I can open up a table within the IDE. OS is windows 10 pro 64 bit.
I have tried uninstalling ms office, and then downloading and installing the access 2013 database engine, the 64 bit version one. If I drop a TADOConnection on a new project, there are no MS ACE 12 or 15 providers. If I uninstall the 64 bit database engine, and install the 32 bit database engine, I see providers in both delphi 32 and 64 bit target platforms. I tried installing the 64 bit database engine using the "passive" parameter but microsoft has apparently caught on to this trick and will give the usual error message about you cannot install both 32 and 64 bit versions. So I tried using the 2010 versions of the database engines and still get error messages, although different ones.
It just feels like I'm missing something here. The weird thing is that in the IDE, using 32 bit access engine and 64 bit delphi target platform, I can make the connection active and open a table. But if I try and open a table at run time I get the error. I have also tried uninstalling and reinstalling delphi.
Ok so the short answer is yes it will work, but there are a few caveats:
You can only install either the 32 bit or 64 bit access 2013 engine drivers or Office, or any combination of those two. Microsoft has disabled the /passive or /quiet way to bypass that. So you can't install both 32 bit and 64 bit at the same time. (at least in a straightforward manner) You can go to control panel and see which ODBC drivers are installed via admin tools.
The IDE is 32 bit, and can only see 32 bit access engine providers when they are installed (via tadoconnect build data provider). Any 64 bit providers installed are not visible in the tadoconnect build connection string wizard.
The good news is that the 32 bit and 64 bit access engine providers have exactly the same provider name. So if you install the 32 bit drivers, create your 32 bit project, you can also create your 64 bit target as well.
with 32 bit drivers installed, your 32 bit target application will debug and run normally. If you try and run the 64 bit target, you'll get "provider not found"
with 64 bit drivers installed, your 64 bit target application will run normally, and the 32 bit application will give the "provider not found" error. In addition, in the IDE, you will not be able to see the data provider via the build connection string in tadoconnect, just leave it alone as it has the exact same name. You can run or debug your 64 bit app, just assume the data provider is correct even though you can't see it.
A thanks to Ken White for a point in the right direction.
Just when I thought I understood Microsoft's confusing naming with regard to WIN32 and WIN64 registry and folders I read this article (Using 32-bit or 64-bit ActiveX Components on x64 Windows) and find myself still a bit confused on how to properly register 32 bit and 64 bit OCX controls on the same WIN64 computer. From the article it says that on a WIN64 system the default regsvr32 is for registering 64 bit OCX controls and to register 32 bit versions of the OCX control I should use C:\windows\syswow64\regsvr32.exe. The thing is I've been registering my WIN32 OCX control using the default regsvr32.exe (in C:\windows\system32) and it seems to have been working fine when I run my 32 bit app which uses the 32 bit OCX. I have the following questions:
Q1 How has registering WIN32 OCX with default regsvr32 been working given what I read in the article.
Q2 I want to register both the WIN32 and WIN64 versions of the OCX control on a single computer. From the article it seems like I should use the two different versions of regsvr32.exe from syswow64 and system32 for WIN32 and WIN64 versions respectively. Is this correct?
Q3 Can the GUID for the OCX be the same for both the WIN32 and WIN64 versions? I'm thinking it can be the same since a different portion of the registry is used to register for each of these architectures. Correct?
Q4 Where do I look in the registry to confirm that both 64 and 32 bit versions of the OCX have been registered to confirm that registering the 2nd one didn't overwrite the first one?
Per suggestion in comment by Andrew here is my comments as an answer.
A1 & A2 Well since no one has replied to this I'll add what I've learned since posting. It seems the article I referenced is misleading in describing how to run 32 and 64 bit regsvr32.exe. From my own testing it seems that the default 64 bit regsvr32.exe can be used to register both 32bit and 64bit OCX controls. It seems regsvr32 (the 64 bit version at least) looks at the target OCX or DLL file and determines if it is 32 or 64 bit and installs it in the appropriate registry. There doesn't seem to be any need to use the 32 bit version of regsvr32 on 64bit windows.
A3 Yes both 64 and 32 bit versions can be registered which use the same GUID.
A4 For 32bit OCX in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID area of the registry and for 64 bit its in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
I just added the '64 bits platform' to my project and my Delphi (XE7) keeps generating a huge RSM file (which increases the compilation time). According to the Help this should not happen if the 'Include remote debug symbols' option is disabled.
And in my case it is disabled.
There is something else to be disabled?
from http://embarcadero.newsgroups.archived.at/public.delphi.ide/201203/12030416462.html
Delphi XE2 generates RSM files that are several MB in size. As I
understand it, these files are for remote debugging. Is there a way
to turn off the generation of these files?
Yes. In the Project Options look on the page "Delphi Compiler\Linking"
for "Include remote debug symbols" and turn it off if you do Win32
debugging. Note it is necessary for Win64 debugging.
and continuing on http://www.devsuperpage.com/search/Articles.aspx?G=2&ArtID=20168
The IDE is 32-bit, because that's the only way it can work on both 32
and 64 bit versions of Windows. (Win64 can run 32 bit apps, but Win32
can't run 64 bit apps.) That's why the remote debugger is used for 64
bit and cross-platform apps.
Jeff Overcash from TeamB
Is the reason that Delphi XE2 is not itself really 64-bit?
Sure, then it can't be run on 32 bit OS's. All third party components
won't work at all until a 64 bit version of it exists (a 64 bit IDE
would not be able to load a 32 bit bpl), this would be a major reason
for people not to upgrade too. Supporting both a 32 bit and 64 bit
IDE doubles the testing time for little to no benefit.
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!
I recently got a new laptop. Unfortunately, it came with Vista. It's been one big hassle getting it to work, and the comp has hardware components for which there are no XP drivers, so I can't "upgrade" to an OS that actually works. I've mostly gotten things working, but one particularly odd problem has me stumped.
I installed Delphi and tried to build a project. It compiled, but wouldn't run. "This application failed to start because sdl.dll was not found." Fair enough. So I grabbed SDL.dll and put it in the C:\windows\system32 folder. (Using Vista 64-bit Home Premium. This is a 32-bit dll, though, so I put it in the 32 folder instead of the 64 one.)
Hit Run again. Same problem. But why? That's where it goes, right? And C:\windows\system32 is in the system path. Anyone know why it can't link to the DLL?
(And yes, I know that I can work around the problem by putting the DLL in the same folder as the .exe. I'm currently doing that as a workaround. It's a bad idea in the long term, though, because I have a handful of different projects that all require SDL.)
That is not a Vista problem, but a 64 bit Windows problem: The name System32 is really confusing, but this is actually the folder where the systems (64 bit) DLLs reside.
So on any 64 bit version of Windows...
... all 64 bit system DLLs are located in C:\Windows\System32.
... all 32 bit system DLLs are located in C:\Windows\SysWOW64.
The name comes from Windows on Windows 64 (WOW64) which is the name of the translation layer allowing 32 bit applications to use the native 64 bit system resources.
Raymond Chen recently addressed the basic reason behind why 32-bit system directories are weird on 64-bit Windows. The first paragraph of the entry is really the key to understanding the reason behind segregated 32-bit directories:
On 64-bit Windows, 32-bit programs run
in an emulation layer...If a 32-bit
program tries to look at the system,
it will see a 32-bit system.
I think you'd have to have separate directories to keep these things all separate and working. The seemingly counter-intuitive name of SysWOW64 for the directory where the files reside is makes more sense when you consider that WOW64 means Windows On Windows 64-bit, which is what the emulater that's mentioned above is called.