RAD Studio 10.4.2 C++Builder running on Windows 10 Pro 64-bit PC. Target VCL Win64 (ie Clang64 compiler).
I have a large C++ project that is under development using VCL Clang64. I am compiling using static linking of all RTL libraries and all installed component packages.
It was compiling and running OK before. I've added some new stuff, and now it compiles and links without reporting any errors, but when I run it I get an error box and the application doesn't run (doesn't even start up). The error box says.
Error reading OKBitBtn.Kind: Resource BBOK not found
I have used Notepad++ "find in files" to search all directories for a file containing BBOK, but it says "none found".
If I compile with the "Use runtime packages" project option enabled, I get an AV when I try to run the EXE file.
If I compile and link using Clang32 (target = Win32) with static linking, it runs ok - no sign of any errors (but I need a 64-bit application to interface to my PostgreSQL database using FireDAC, so this experiment won't talk to the database, as expected).
I am at a loss as to what can cause this error, and what debugging steps I should take to track it down and solve it.
(thanks to Remy for making edit improvements to my mquestion)
Thanks to help from David Millington and Miguel Moreno (provided by skype conversation I now have the solution:
I have some of my own VCL components that are written in C++ (and work with the classic compiler). I had these de-selected in the "installed packages" list - but they were still listed (with empty check boxes). I know that RAD studio 10.4.2 (and earlier) does not work well with VCL components written in C++ and compiled with clang32 or clang64 compilers.
If I "remove" these components from the list then the problem is solved. At this point I have no idea why this happens.
This is a bit of a pain as it means swapping from projects that use the components with classic compiler (many) to the big project I am spending a lot of time on is not convenient. However it is an acceptable workaround. I am hoping that this issue will be fixed in the coming RAD Studio 11 version.
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
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"
Is there any way to access 64bit exe-files with a 32bit app?
I am using Delphi 2009 (upgrade to XE2 is not possible, moneywise, right now)
I am making this launcher, and when running it on win7 64bit, it doesn't pickup the right icons for 64bit apps, and ShellExecute doesn't seem to work either with those apps.
Now, all these apps are in "C:\program files" which suggests that this is a WOW64 thing.
I have googled various ways to temporarily disable wow-redirection, but none seems to work.
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.