I'm creating a windows application in vb.net which I want to be able to compile for "All CPUs". Now,i want compile the app in 64 bit ActiveX controls for that i have change from All CPU to x64 and i compile the app but it showing error that could not find the Xceed-controls.How resolve this errors .
Related
I programmed a custom-component and tried to install it in my Delphi 10.1 environment.
I only had a .Pas-file.
I went to:
Components - Install-Components, selected my Unit which is in a new folder on my desktop -> made a new package in the same directory -> hit finish
now when I open my packege in the IDE and set the platform to windows 64Bit I can compile but not install my component.
my component is derived from the TEdit-control, don't know if this is relevant.
in my requires list are the following:
dbrtl.dcp
rtl.dcp
vcl.dcp
vclactnband.dcp
vcldb.dcp
vclx.dcp
xmlrtl.dcp
I'd really like to use my component in 32Bit-applications as well as 64Bit applications.
Other VCL-Controls provided by the IDE have no problem compiling in a 64Bit application, but my component is greyed out when I set my project to 64Bit.
I'm on win8.1 64Bit.
The IDE is a 32 bit process. Therefore you can only install 32 bit packages. However, the runtime, 64 bit programs can use your component. Either by linking it directly, or by runtime packages. In the latter case, you would need to supply a 64 bit runtime package.
This is covered in some detail by the documentation: http://docwiki.embarcadero.com/RADStudio/en/64-bit_Windows_Application_Development#Considerations_for_64-bit_Applications
Are there any problems with programs that are compiled with Delphi 2010, using Rave reports (no database connection) running on Windows 10?
In principle, there's no reason why a program compiled with Delphi 2010 will not work perfectly well on Windows 10. Indeed, a program compiled with any 32 bit version of Delphi (Delphi 2 or later) can, in principle, be executed on Windows 10.
The usual caveats apply though. You have to make sure that your code respects features like UAC. So don't attempt to write to HKLM, system directories, etc. as standard user.
As a broad guideline, if your program executes on Windows 8.1, you can expect it to execute on Windows 10 also.
So, in summary, you should be perfectly capable of producing a program that runs on Windows 10 using Delphi 2010. However, it's impossible for anyone to tell you definitively that your program will run because only you know the full details of how your program is implemented. You should test your program on each new operating system as it is released, if not before it is released.
I'm not sure, but the internal Kernel ID from Windows is set from 6.x (Windows Vista - Windows 8.1) to 10.0 (Windows 10) so this can be a problem.
Actually we have integrated Teechart in our application and it works fine on windows 7 64 bit.
But now we moved to windowss 8 where our application 32 bit works fine with Teechart but 64 bit gives access violation error.
we taught it might be our issue so we build samople application seriesTxt source and tried to execute we found that the Teeeditor is disable and in out code we used it to set legend size that where it crashes.
Can you please execute the sample code in the Example by building in 64 bit and check on wwindows 8 (64 bit) whether it works fine.
Also we found out the issue might be because of casting some variable in DWORD which work in windows 7 but windows 8 required the type casting to be DWORD64 may be some where in your code this can be the issue.
Thanks
Akshay
Note we changed the CLSIDs of the components on TeeChart ActiveX v2014.0.0.2.
However, I'm afraid the demo in the "Examples\Visual C++\Version 6\SeriesTextSource" folder still references the old CLSIDs.
Updating them I could build and run the project without errors in Visual Studio 2010 here, both in 32 and 64bit, in a Windows 8.1 64bit machine.
Find here the corrected project:
http://goo.gl/7Ro3OS
Also check you have both the 32bit and the 64bit versions of the .ocx registered. To register them, open an elevated command prompt at the TeeChart installation path and run:
regsvr32 "TeeChart2014.ocx"
regsvr32 "64bit files\TeeChart201464.ocx"
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 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!