I try to debug a COM+ DLL in Delphi 7 in a Win7 environment. How can I do this?
It's possible with a work around.
1 unregister from Com+ the dll
2 run as administrator in cmd : regsvr32.exe
3 Make a break point
4 In Delphi 7 Run -> Parameters : Host Application : Exe Application that use the interface dll
so the step 2 is the key ...
If it is mostly the debugging you are concerned about, not necessarily debugging in Windows 7 64, you could set up a virtual computer running Windows 7 32 bit, or, since you seem happy with older technologies, drop back to XP. You'll need to set up your development environment there, but at least you'll have a full running virtual machine that you can back up or move if you want to.
Related
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 an Delphi 7 Application that uses Halcyon dbf component. It works well in Windows ME.
Unfortunately in Windows XP data aware controls which are bound to Halcyon xBase Engine do not behave correctly. In addition pack command almost hangs the application. I tried compiling in XP. But no joy. Does that mean that API calls work differently? May be Data types mean different things....
Thanks for all help
A well written Delphi 7 application will work on any version of WIndows from 98 onwards. If you have managed to make an application that doesn't work on XP, then you should debug the problem on XP, not recompile and then give up. (no joy!? what? you're done already? Is that how you troubleshoot and debug?).
For posterity I should point out that if you change Delphi versions then of course, some things change. For example, If you build your Delphi application in Delphi 2009 or later, it will work properly on Windows XP, but not on Windows 98 or ME any more. But if you build your application using the same version of Delphi, why would you expect any changes in the application's bugs?
As David says; Rebuilding your application on a different computer, from the same code, and with the same compiler, produces the same binary. If you have a fundamental problem on Windows XP it is because you made a mistake in your code somewhere.
In general, windows 98/ME to 2000/XP was an easy transition, but that was a decade ago.
The only API I remember that was in Windows 98/ME that was not in XP, was the Windows 98 text-to-speech API which was removed and replaced with a different API in XP.
I believe your confusion is that windows contains something that affects Data Aware controls. It does not. Data Aware Controls are a purely Delphi thing, and they are not a part of Windows XP, they are 100% implemented inside Delphi. If you have some funny custom control that is badly written, perhaps it might not work. We have no idea what your code contains, and you haven't even described the nature of the failure.
You need to provide more information, or this question should be closed as unanswerable, or too localized. (My app doesn't work! Help! No other info given.)
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!