I have a strange problem which I don't know where it came from. I might have changed some settings in the MSVC++2010 project but it all looks good to me.
I'm currently experimenting with the VSHADOW.EXE 3.0 tool included with Windows SDK 6.1. This is a sort of backup program written in C++ and the strings in it are composed of wchar_ts. Now, my arguments (such as -q) which I pass to the program always result in strings of japanese symbols in the program. This occurs if I start the program normally via cmd, but also if I specify commandline arguments in the Visual Studio project settings and start the debugger.
Does someone have an idea how to solve this problem? Thanks!
Problem solved, I changed wmain to main for a test and forgot to change it back.
Related
I have a problem with a program I made in visual studio 2019.
The code itself, or the algorithm is not wrong, because it works properly as I intended.
Yet, I got a problem, as I was adding patches to support other languages.
I added the Korean and Spanish versions, but the Korean version comes out well but the Spanish don't.
If you can see in that photo, which is the first scene of my program, the English and Korean characters' outputs are fine but for Spanish, it is printed as "Espa?ol", which is supposed to be printed as "Español".
I believe this is some presets problem or lack of language packs (which are related to Unicode systems) or so but I couldn't find anything to fix this problem.
How can I fix this problem and let the Spanish characters appear properly?
For your information, I am using C++ in VS2019 and used the "string" type for all statements.
I am requesting your help to fix this problem.
Thank you for your generosity.
It seems you need two things:
Setting execution character set for your VC++ project.
https://learn.microsoft.com/en-us/cpp/build/reference/execution-charset-set-execution-character-set?view=vs-2019
Basically adding compiler option /utf-8 to Configuration Properties, C/C++, Command Line.
Changing the code page for the console. Visual Studio use cmd for console application, and cmd may not handle Unicode character properly.
You can execute your .exe program from an independent cmd instead, using an Unicode code page:
cmd>chcp 65001
cmd>out.exe
Hello Español!
Or calling the chcp command from inside your program.
system("chcp 65001");
cout << "Hello Español!" << endl;
I'm a beginner in C++ and I started an Udemy course. In that course they recommend using CodeLite as IDE, so I decided to give it a try. In the course, they write a basic program that displays "Hello world!" to show how the IDE works. They compile then execute it, and a terminal window opens with the "Hello world!" message like normal.
In my case, after following the setup process step by step and using the exact same code as them, when I compile and execute the code, my terminal flashes for a split second and then disappears. In their video the terminal remains open but I thought that since they have an older version of CodeLite maybe in the newer one that I have, the terminal is supposed to close by default.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause"); on Windows, but in my case the terminal keeps behaving the same, and CodeLite doesn't report any problems. I've also tried cin.get(); with no success.
Any idea what could be causing this problem?
I had the same problem and I did these steps to solve the problem:
Uninstalled CodeLite.
Installed MinGW correctly.
Then reinstalled CodeLite.
Then did tutorial steps: Click Scan then select MinGW.
After I did these steps, it worked normally.
I had the same problem running Codelite on OpenSuse Leap 15.1. I eventually found a very simple answer. Go to the Settings menu, select Preferences and then Terminal, on the left towards the bottom. Change it to konsole to use the standard terminal, rather than the codelite-terminal.
I know this is an old question, but did not see the answer that worked for me. Debugging (F5) will close the terminal after completion.
However, running/executing (CTRL+F5) will not. Leaves terminal open. At least this is the case for me, and hopefully this helps someone out.
I know this is an old question, but CodeLite has a Project-level setting for "pause when execution ends" which will pause the program before the terminal closes so that you can see outputs and the like.
To turn on just right click on your project, go to settings, and it should be in the center of the general tab.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause");
And this is the wrong way to do it - the desire to leave the window open/closed is not meant to be controlled by your program; but the thing calling it. For example, you break the ability to run it as part of a headless script.
Much better would be to run it in debug and put a break point at the return of main, or to find the configuration option in your IDE that stops it closing the window.
I am not aware why CodeLite would behave like that. If you really added some pause or blocking call and it still closes, it looks like it is not really running the program (e.g. something breaks before that or something is misconfigured).
First, try to open a terminal yourself (e.g. cmd or PowerShell on Windows), and execute your compiled program there -- that way, the terminal will remain open. If that works, then compilation went fine, but something is wrong with CodeLite's configuration, most likely.
Otherwise, as a last resort, since using CodeLite is not strictly required, simply switch to another IDE/toolchain, e.g. Visual Studio (on Windows).
For some reason, after closing and reopening CodeLite, it now works, the terminal remains open when I run it from the IDE. I don't know what solved the problem since I've closed and reopened CodeLite at least 5 times before this without anything happening. Thanks for the help though.
I had the same issue. What I found wrong was that the compiler that I installed was 32bit and I was using the 64bit CodeLite version . Try Installing the 32bit CodeLite version and it should work fine.
It worked for me.
I had this problem also, I tried uninstalling and reinstalling code lite but the problem still occurred.
I went back and checked the Environment Variables in control panel and I had placed the systems variables in "Path" to the incorrect Bin directory.
I corrected the entry, uninstalled and reinstalled code lite again and the problem was resolved.
Hey I also had the same problem, doing the same course! What I did was to relocate my mingw-w64 folder, deleted the earlier path from environment variables and added the new path. I uninstalled CodeLite; not saving the user information. I actually downloaded the 14.0.0(64-bit) instead of the newer version 14.0.1(64 bit) . Then I did the steps that Frank tells you and it worked out for me.
I am completing the same Udemy course and encountered a similar problem of the console closing immediately. I encountered the problem for a workspace with 1.) a long name and 2.) ending with an underscore "_". I reduced the size of the folder name which also involved deleting the trailing underscore. This appears to have solved the problem. I encountered this problem with one of Frank's provided workspaces so I knew it was not a compiler issue.
I had an issue with section 20 of my Udemy course because it had parenthesis in the workspace folder name. "(STL)" at the end. Once I got rid of the special characters, it worked fine.
If pause("system"); or cin or restarting Program and whole PC solutions are not working, then make sure to:
Copy your code.
Create new Project and past your code there.
Make sure the new project is selected before trying to double-click it.
Notes:
You can now delete the old not working project and rename your new project.
I don't know what's the reason of the problem, but I did that and it worked for me.
You need to make sure if it is 64bits CodeLite then you have installed 64bits MinGW. Through the IDE itself, you can re-run the setup wizard
Restarting Codelite worked for me ...
It's my first time using Visual Studio 2017. I built a simple program in C++ on my PC. I was curious to see if my program works on another PC. I tried to execute the .exe on the other computer and it gave me this kind of error:
vs(some letters and numbers).dll is missing.
I assume that the .dll in question is part of Visual Studio.
I tried on a third PC, and this time the cmd stops working and becomes unresponsive after I execute my .exe.
I also have this problem when I compile with MinGW using the g++ compile feature in the cmd. When I execute the program compiled with MinGW on another PC, it gives me the same error, but this time it says something like
gw...dll is missing
Is there a way to avoid this error without installing the Visual Studio (or MinGW at this point) on any other PC I want my program to run on?
If you're interested in the code, I can put it here, but I don't think it's the problem here because I have the same issue for every other .exe compiled on my PC.
Here's a picture of the error:
In case of Visual Studio, you need to install Visual C++ Redistributable libraries or provide the libraries that are required by your application with .exe file (I am not sure if it violates license or not though).
In case of MinGW, you need to provide required DLL as well. I guess that you need libgcc_s_dw2-1.dll and libstdc++-6.dll, but you would better check it yourself. And remember about the license.
You may use Dependency Walker to analyse dependencies of your application.
UPDATE (2017-12-12):
I've missed the time you posted the screenshot. As far as I see from it the problem is that you are trying to run debug version of your executable: ucrtbased.dll is the debug version of the ucrtbase library and is only available (from what I know) from Visual Studio distribution. If you want to run your application on the computers that do not have installed Visual Studio, then you should use the Release version of your application.
In order to understand your problem you need to understand the concept of DLL.
Dynamic-link library(DLL) - As described by Microsoft:
A DLL is a library that contains code and data that can be used by
more than one program at the same time. For example, in Windows
operating systems, the Comdlg32 DLL performs common dialog box related
functions. Therefore, each program can use the functionality that is
contained in this DLL to implement an Open dialog box. This helps
promote code reuse and efficient memory usage.
So to put it simply, DLL is basically a bunch of compiled code, which is being linked to your code at load (or even run-time). Now, of course if your system is missing the DLL, your progrem will fail to work. To make things even worse, DLL are sensitive to the compiler that was used. So each DLL might have multiple version, so you will need to right DLL.
Now to the problem itself, the error message are the best way to start. They guide you what DLL are missing, and what is their name. For instance in your case "vs*.dll" is most likely related to Visual C++ runtime redistributable.
Finally, please note you have another consideration to make in addition to make your own system work: Every one that will use your code might face the exact same problem. So if you actually intend to share your .EXE with other people, you will need to understand how to guide them, or even automate their installation process.
sometimes I have to debug an application that was written with Borland C++ Builder. This application loads dlls compiled with Visual C++. Is there a debugger that can debug both parts of the application? Currently I have to decide - either I can easily set break points and see the source in Visual Studio or I have to start Borland C++, but I can't work with the source from the Visual-Studio compiled dll.
thank you for your help,
Tobias
You could try OllyDbg - version 1.x does not seem to support the latest Win version but there is also the 2.0 although it's still in alpha state(haven't tried myself that one yet).
EDIT - clarification:
Source debugging OllyDbg reads debugging information in Borland and
Microsoft formats. This information includes source code and names of
functions, labels, global and static variables. Support for dynamical
(stack) variables and structures is very limited.
The above is take from here.
UPDATE:
I'm not familiar with the Borland C++ Builder but at this link you can find some articles explaining how to deal with some interoperability issues between Borland and MS that might be of help.
if both parts built using ulink linker and have debug info you could try cdb32 debugger (from the ulink linker author)
cdb32 is still in its alpha stage though and I personally never tried such "mixed" debugging
Have you tried loading the DLL code in VS, loading the app code in BCB, and having both debuggers attached to the same running process at the same time? Not sure if Windows will allow that, but it might be worth a try.
I suspect there is no perfect answer to your question, you are going to have to compromise in some way, as I'm sure you are already doing.
I have a similar problem to yours at work. The applications that I work on are written in Python instead of Borland C++, but like your situation, these apps rely on a rather large Visual Studio compiled DLL for some functions.
My method of debugging these applications involves a combination of two debugging strategies: the use of an interactive debugger and the so called "printf" debugging technique.
What I basically do is pick one of the two areas as my main debug focus, and that determines my debugging approach:
If for a given situation I decide that I need to debug the DLL with greater detail, then I work with the VS debugger. I set the executable to run in the DLL project as my python script and that enables full debugging of the DLL code. If I need debugging support from the Python side, then I add print statements. If I need a breakpoint on the Python side to inspect some values, I just print all those values and immediately after call a C++ function that does nothing, but that has a breakpoint set in VS.
When I need to concentrate more on the Python side more I use a Python interactive debugger, but I have VS with the DLL project loaded on the side so that I can quickly add any necessary printfs on the DLL and recompile, so essentially the reverse of the above.
I know it's not the answer you expect, but it is a decent solution in my opinion.
It looks that it is possible to convert the debugging information generated by C++ Builder to a format understood by WinDbg (link to discussion). If so you could use it to debug both parts of your application (I haven't tried this though).
you can convert the .map files to Microsoft's debug file format
http://code.google.com/p/map2dbg/
now you can use Windebug; there is also a tool mentioned to convert to pdb format, so you could try the vc++ debugger
I know the title makes little sense, mostly because it's hard to explain in just one line. So here's the situation:
I have a program who's binary is targeted at Windows 2000 and newer. Now, I went ahead and added some code to check if the user is running under Vista/7, and if so then check if Aero/DWM is enabled. Based on this I'll disable some stuff that isn't relevant to that particular platform, and enable some other features. My main problem is that in order to call DwmIsCompositionEnabled from Visual C++ 2008 I have to add the dwmapi.lib file and compile against it. Running the binary in anything other than Vista or 7 gives the "Unable to locate component. The application failed to start because dwmapi.dll was not found" error. This, of course, is expected to happen since DWM is new and not available for older platforms.
My question is then: will it be possible for me to somehow manage to pull this off? One binary for all OS versions AND include that DWM check code? This program was written under Visual Studio 2008, Visual C++ using MFC.
Turns out I can just tell the linker to delayload the dwmapi.dll.
I'd like to thank ewanm89 because something he said sort of resonated and led me down the path to finding the actual answer.
The normal solution is to use LoadLibrary() and GetProcAddress(). Both can be done after your program started. But still +1 for the DelayLoad solution, which does the same for you behind the scenes.