I installed the latest Chromium Embbed version on XE6, did a test using demo guiclient and worked very well. But when I create a new app and put TChromium component receive this error:
I did the tips on this question.
Usually that means that a 32 bit process is attempting to load a 64 bit module, or vice versa. You need to do a bit of debugging, for instance using Dependency Viewer, to work out which module has the wrong bitness.
One obvious possibility is that your host process is 64 bit and the CEF libraries are 32 bit. To fix that you would need to switch your process to be 32 bit, or find 64 bit CEF libraries. I'm not even sure if the latter exist.
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.
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 have developed a Delphi application (XE4) on a Windows XP machine.
When I copy all the project files to a Win 7 machine (also Delphi XE4) it will not compile.
The source has uses Vcl.Grids and the compiler complains it can't find vcl.grids.dcu.
Changing to uses grids works but I don't want to edit all the source.
I've checked the Embarcadero website for information on Namespaces but couldn't find anything useful.
I know it's possible to say uses vcl.grids under Win 7 so there must be some setting somewhere in the project that is preventing the resolution.
I've tried deleting the dproj files but that had no effect.
How do I get the source to compile with minimal changes?
The error has nothing to do with OS. It means your IDE/Projects's search paths are not configured correctly, or your project is missing references to the relevant packages, so double check that.
Also, you can use uses Grids in the code, and then make sure Vcl is listed in the Unit scope names field in the Project Options.
The information that you describe seems to be erroneous. The compiler is not affected by the operating system on which it runs. Running the same compiler on the same source code on a different operating system does not result in compiler errors.
Here are the reasonable explanations for your problem:
You are compiling the code on different versions of the compiler. Your error message matches what happens when you compile modern namespace aware code on XE or earlier.
Your are not compiling the same source code on both machines.
It is extremely hard to see beyond these two explanations.
Ok, red face time. Turns out I was running an earlier version of Delphi on the Win 7 machine. Delphi XE4 was installed along with an earlier version and I was invoking the earlier version.
Once I actually brought up XE4 on the Win 7 machine the issue vanished.
So I will don a hair shirt and crawl under my rock.
Thanks everyone who contributed.
I have one executable. Exe is prepared from Delphi version 5 as code is written in Delphi. This exe working successfully on Windows XP, Windows 7 with 32 bit operating system. But same executable not working on Windows 7 with 64 bit operating system. It will throw following error code Exception code: 0xc0000005.
The only option is to re compile the Delphi code and make it compatible to Windows 7 64 bit operating system.
I have Google but do not find any suitable article. Therefore, can someone please help me out to resolve this issue.
I have good idea to make executable compatible for 32 and 64 bit but only in .NET Framework. So Please help me.
That error code is the NTSTATUS code for an access violation. For you to see that error code typically means that your application has raised an access violation during initialization. Once the Delphi RTL has initialized then those errors are converted into native Delphi EAccessViolation errors. So with high probability this is an error during initialization, possibly related to the way you link to or use a dependent module.
In order to solve the problem you need to do some debugging. The first thing I would do is to use Dependency Walker in profile mode to run your application. This will give you diagnostics of the load of your process at some point, presumably during the load an initialization of a module, you will see an error. Hopefully this will lead you to a solution.
Programs built with Delphi 5 do run on 64 bit Windows. You have an error in your program that needs debugging. Simple as that. Not the easiest error to debug, but it's still just a debugging exercise with your code.
I am writing a program in Delphi, and including a library which contains some assembly code (Pipes.pas). I am getting an access violation when I run the code which makes a call to a function called StdWndProc. The process is an assembly function which contains assembly code.
A while back I updated this code (Pipes.pas) to include unicode support and other stuff, but I didn't figure out what this assembly was doing. Any ideas on what's going wrong here?
I'm running on a 64-bit machine, could it be that this assembly is 32-bit and isn't running correctly on a 64-bit processor (the project is targeted at 32-bit build).
A 32 bit process executes 32 bit code. It doesn't matter whether that code was compiled from assembler or Delphi or some other language.
It doesn't matter whether the machine is 64 bit or 32 bit, a 32 bit process runs 32 bit code. On a 64 bit machine, a 32 bit process runs in an emulated 32 bit machine called WOW64.
Conceptually what you are attempting is possible, so the conclusion is that your code has a bug.
As David Heffernan pointed out the cause of your problem can hardly be the OS architecture.
If your code runs with no errors on 32 bit machines, but it fails to run on 64 bit ones, it could be an OS issue however. It could be caused because of the use of 32 bit-exclusive directories (like SD:\Program Files which is called SD:\Program Files(x86) on 64 bit windows for 32 bit programs), registry reflection (which causes your program to store registry data under the Wow3264Node key), or even the use of old 16 bit DLL s (that can not run under wow3264), but that is a very rare case since it is 2013...
To be able to help I need further details of how your code does not run correctly.
(Please note, that the original question is already answered, I only wanted to provide some more useful help.)