I'm new in DirectX and I found a strange problem. I've installed DX11 SDK in my computer and I have a 64-bit windows 7.And I use MSVS2010.
But when I try to use DXTRACE_MSG Macro in my program I found a link error error LNK2019: unresolved external symbol _DXTraceA#20. I set my library path as $(DXSDK_DIR)\Lib\x64;
But when I tried to change my library path to $(DXSDK_DIR)\Lib\x86; It worked perfect.
So I'm confused that whether cause of the problem is something setting wrong in my IDE or anything else?
Sorry for my poor English and thanks for your time and attention.
A 64-bit operating system does not mean your DirectX program is also 64bit, If you link 64bit version libs to a 32bit app, you will got the errors.
To create/check a 64bit version app with visual studio 2010, please see this topic.
Related
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'm using the new Delphi Tokyo 10.2.2 and, in my case, I use packages loaded at runtime.
Even making a simple example and requesting EXE to load only the RTL unit occurs a run-time error, only on the Windows XP operating system:
The procedure entry point inet_ntop could not be located in the dynamic link library WS2_32.dll.
Using Delphi Tokyo 10.2.1 the problem does not happen.
Any idea?
I have a new project proxy functions to all exported functions of original Windows XP's WS2_32.dll including inet_pton that was missing in Windows XP's WS2_32.dll.
It tricks the Windows XP application process to think that inet_pton is available and not prompting any errors.
Repository: https://github.com/ccy/WS2_32_XP
inet_ntop() was added to Winsock in Windows Vista, it does not exist in XP.
Clearly, Embarcadero has added new code to the RTL in 10.2.2 that is calling inet_ntop() statically instead of dynamically. Code that did not exist in the RTL in 10.2.1. That is why the error is happening when loading 10.2.2's RTL package on XP.
There is nothing you can do about that. If you must run your app on XP, (which Embarcadero dropped support for way back in XE3), then you can't use the 10.2.2 RTL.
All,
I was able to solve the problem by creating a package with all the necessary units embbed.
Then the executable and the other BPL (modules) referring to this single new package.
It worked again in win XP!
Thank you all for the support
I'm trying to move a project that was done in a previous version of C++Builder to 10.1 Berlin (I am using the trial version of C++Builder).
The project was converted and compiled succefully with minimal efforts. Then I got the well-known linker LME288 problem, but it was resolved by starting C++Builder as an administrator.
But now, when I start the application, I get a message box saying "Abnormal program termination" at the very beginning - even before the main window appears on screen.
The situation is the same for debug and release versions, under IDE and as standalone. When I start the program inside the IDE, and set a breakpoint at the very first statement, the error message appears before this statement.
I have Windows 10 Pro, 64-bit. C++Builer 10.1 Berlin trial. It shows the only accessible platform is Win32, but I don't know if this is a reason for an error. The program worked fine for previous versions.
Could anybody advise me what to do? Is there a systematic way of investigating the problem?
I have tried all recommendations I could found - use debugger, show us the code, try reinstalling software or Windows, upgrade to latest updates, etc. But I have never seen a systematic approach.
Here are a couple of things I had to do to get my project working.
1) Start a new project. For some reason old projects can get corrupted and produce strange errors. I recommend starting a new project and adding your files to it.
2) Use an old version of borlndmm.dll The version provided with C++ Builder 10 produced crashes for me that made no sense. I overwrote the provided copy of borlndmm.dll with a copy from XE6 or XE8. That solved my problem.
Hopefully one of these will help you.
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.
A vendor has developed an ActiveX control in Microsoft C++. The ActiveX worked fine when they were using the 16bit version of the compiler. The control does not work when compiled using the 32bit version within the Delphi2007/D7 environments. If you drop a control on a form and run it throws an "Floating Point Error".
It is a Delphi issue. We are able to use the ActiveX in other applications.
Anyone ever have a similar problem or have a solution for this?
Sounds like an FPU problem - check out Set8087CW in Delphi's help file.