Maybe I just have another black out but, this one line is giving me a lot of troubles:
FILE *fp = fopen("data/world.data", "rb");
This works fine under Linux when compiled with GCC. But when I compile it with Visual Studio, it crashes. fp is always NULL. Both the BIN and the EXE are in the exact same directory. Now, to make things even crazier, when I run the EXE using Wine under Linux... it... works...
I have absolutely not a god damn clue what's going on here. Maybe it's some insanely stupid mistake on my side, but I cannot get this thing to run under Windows :/
Also, I have another program which works just fine, there the data files are also contained in a sub directory named data.
EDIT:
To make it clear neither / NOR `\ * do work.
EDIT 2:
OK I've given up on this, maybe someone has fun trying to figure it out, here's ZIP containing the EXE, Debug Data for VS etc.:
https://dl.dropbox.com/u/2332843/Leaf.zip
EDIT 3:
Compiled it with CodeBlocks and MinGW, works like a charm. Guess it has to do something with MSVC or the Project Settings in VS.
It sounds like data isn't a subdirectory of your current directory when you run the program. By default (for x86 targets) VS will build and run your program from either a DEBUG or RELEASE subdirectory of the base directory you've created for the project. You can modify the directory that will be "current" when it runs though (e.g., project | properties | configuration properties | debugging for VS 2008).
Edit: While Windows requires that you use a backslash as a directory separator at the command line, a forward slash works fine in code -- this is not the source of your problem.
In windows you have to write the following:
FILE *fp = fopen("data\\world.data", "rb");
This is like that because the backslash is a special character (so a backslash in a string is written using \ and a quotation symbol is \" and so with other special characters).
Since this issue happens only on windows. I doubt whether the file is really named "world.data". As you know, the default setting for windows hides the file extention. Is its real name world.data.xxx?
Include a line to GetCurrentDirectory(), to see if you are running from the directory you expected.
When I develop in C#/ C++ on visual studio, I normally get to run it from the debug folder. I don't think it matters if forward slash is used in place of backslash in .net.
I happened to have the same problem, and suddenly i figured it out.
That should be your windows fault.
Let's say, FILE *fp = fopen("data/world.data", "rb"); in windows, if you hide the extensions, then you can see the file data/world.data, but actually it maybe /data/world.dat.txt or somewhat.
So please check the extensions.
Hope it helps!
I ran into this today, and it happened because I used "br" instead of "rb" on that mode argument.
The underlying fopen is throwing an exception of some kind, which only registers as a crash. It's not bothering to return the standard NULL response or set the associated error values.
I'm not sure but it may be because you're using slash instead of (an escaped) backslash in the path?
Related
Things that i should note are that I am using the latest version of vs code to write in c, my compiler is mingw-w64. Whenever I run a simple code (Hello world for example) everything works then suddendly when I try to do something else a message appears saying (program name).exe was not found. This generally happens when I try to use commands from other libraries, i tries using conio.h textcolor() but it doesn't want to, but when i use getch() it works fine. Moreover the .exe file exists, then i add a single line of code and boom suddendly it doesn't exist. Can anyone explain to me what is going on??
I've a strange behaviour on my pc when a I precompile a .pc source file. I use a command line instruction, like "proc wpd_ric_pla_02.pc wpd_ric_pla_02.c CODE=ANSI_C".
If I compile the very same source file on another machine, with the exact same version of proc (11.1.0.7.0), instead, I have no issue.
I attach an image showing some differences in the .c generated.
You can see on the left the correct .c and, on the right, the .c generated on my machine. SQL instructions are wrongly commented out.
Could someone please help me understand why this happens?
Thank you, Sebastian.
It may have something to do with the file being copied from one machine to the other. But this is only a wild guess.
Maybe the wrong file have some non-visible characters that are messing the compiler.
You can check it by doing a hexdump -c wpd_ric_pla_02.pc if you are in Linux.
If you are using Windows I suggest you use Notepad++ View / Show Symbol / Show All Characters function.
If that doesn't work, try isolting the problem in a single query.
I am facing this error while trying to debug C code in Visual Studio 2010. When searched in google all i could find something related is as below
http://connect.microsoft.com/VisualStudio/feedback/details/615793/badly-formed-debugger-command-causes-error-parameter-basepath-cannot-have-zero-length.
Any suggestions to overcome this is really appreciated . Thanks
Same problem, I was building a function library to load on demand, but got this message. It is a matter of don't quote the VSDebugger options.
Remove the double quotes from
the full path of the executable
the command arguments
the working directory
embedded spaces can be passed to the command line by single quotes, if really required.
I had the same error message with only the name of the executable in the command (so no full path). It used to work pefectly, but suddenly it didn't. I checked the path variable and somehow there were two consecutive ';' in there. I fixed that and the problem disappeared.
In my case the command line did not have .exe extension at the end (Properties->ConfigurationProperties->Debugging->Command). Adding the extension fixed the problem.
For me "Parameter "basePath" cannot have zero length" was caused when I set my configuration properties->debugging->command to "regsvr32.exe $(TargetPath)" to debug my project registration. I fixed this by setting the command to "regsvr32.exe" and command arguments to "$(TargetPath)"
If you set up a makefile project (I guess it's the case), be sure that the file you put in Configuration Properties -> Debugging -> Command exists.
(and I think it doesn't accept batch files, but I'm not 100% sure)
check your path in: Configuration Properties -> Debugging -> Working Directory.
check that this path is a valid path in your machine.
I've solved this problem with setting value of Properties->Debugging->Command to another, and after it set back to my default.
Also make sure Visual Studio is running "As Administrator". This fix it for me.
I am new to this forum. I am in need of a program in C that runs an exe file in Windows.
While googling I found the code below :
1.
Code:
#include<stdlib.h>
#include<stdio.h>
int main()
{
(void)system("C:\\Windows\\notepad.exe");
return 0;
}
The above code compiles successfully in Borland Turbo C. But it fails to run Notepad.
2
Code:
#include<stdlib.h>
#include<stdio.h>
void main()
{
int result ;
result=system("C:\\Windows\\notepad.exe");
printf("%d",result);
}
The above code on running gives -1 as output. Why am I getting -1.
My OS Windows XP
Borland Turbo C Compiler
Please help.
There are at least two wrong things here:
you're using system();
you're hardcoding a path.
For the first problem, I already wrote a long rant some time ago, you can have a look at it here; long story short, to start a process you should go with the platform-specific way, namely, on Windows, CreateProcess or, if you want to open a file with it's associated application, ShellExecute.
For the second problem, you're assuming (1) that c:\windows exists, (2) that it is the windows directory of the currently running windows instance (3) that notepad.exe actually exists and (4) that it is in such directory.
While notepad.exe is pretty much guaranteed to exist on every Windows installation, it's not clear where you should search it. Since Windows 3.0 it was in the Windows directory, but on the NT family it used to stay in the system32 subdirectory. So, from some Windows version onward Microsoft put two copies of notepad, both in the windows directory and in the system32 directory (see this blog post).
Additional fun: from Windows Server 2008 the copy from the Windows directory has been removed (link - incidentally, the title of the post is What idiot would hard-code the path to Notepad? :D), so your program will fail to open notepad even if Windows resides in c:\windows.
But the biggest problem here is that Windows isn't guaranteed to be installed in c:\windows; on every NT-family Windows before Windows XP it was actually installed by default in c:\winnt, so your code would fail here.
Moreover, if you have more than one copy of Windows installed (say Windows 7 64 bit on c:, Windows XP 32 bit on d:) c:\windows may actually exist, but it may contain a copy of Windows different from the one currently executing, so you'd be opening the notepad from another copy of Windows (and if that copy is 64 bit and the running one is 32 bit it won't run).
Similar stuff may happen also if you install Windows on a disk that already contains a windows directory; in that case the setup will put Windows in a Windows(01) directory (or something like that), and c:\windows may be empty.
Long story short:
avoid using system: apart from its other flaws, in all these scenarios your application wouldn't have any clue that notepad didn't start;
avoid hardcoding paths: c:\windows isn't guaranteed to exist; if you need to get the path of the Windows directory, you can expand the environment variable %windir% (or %systemroot), or use the API GetWindowsDirectory;
if your app is in PATH, you may exploit this fact: the Windows and system32 directory are in the PATH environment variable, which means that, if you just try to start notepad, you can avoid to specify it's full path; on the other hand, you're exposing yourself to vulnerabilities if a malicious user put a dangerous application in the working directory of your application;
if you want to open a file, use ShellExecute: it will automatically open that file with the associated application.
I'm not sure notepad has ever been stored in the Windows directory. This code works under WinXP.
#include<stdlib.h>
#include<stdio.h>
/* main() returns int, not void. */
int main( void ) {
int result ;
result=system("C:/Windows/system32/notepad.exe");
printf("%d",result);
return 0;
}
Look where you save your source file, alway C++ Compilers generate two files, let say your source named "hello.cpp"
These files should be in your source path:
hello.obj
hello.exe <--your prgram to distribut
ALSO
I think you should use new free IDE/Compiler for better result such as:CodeBlocks at http://www.codeblocks.org
As per me I dont see any problem with the code, did you try running the program with some standard IDE like, dev-cpp or code-blocks.
And do one thing
try running the same command on the command prompt first and tell the result.
I would also like to tell you to go inside the Windows directory and check if Notepad.exe is there or not.
It is not likely but there is a chance.
Thanks
Alok Kr.
Could be that your path is wrong in some way. I would suggest following Kumar's advice and try running it in the command prompt first just to see that you are using the right path.
Also, you might want to try running notepad.exe without a path at all. As it is located in the PATH, you should be able to specify just "notepad.exe".
I have looked through both the CodeBlocks and MinGW FAQ and wiki to no avail. As stated above I am a noob.
I want CodeBlocks to act like a Unix compiler in that it overwrites a single output file every time it compiles unless told to do otherwise.
In Unix:
[cc example.c] -> [a.out], [cc example2.c] -> [a.out]. If I want to save the output file from being overwritten i just [cc -o newname example3.c] - [newname.out].
If this is possible with CodeBlocks/MinGW on XP I'd like to know how to do it. If not I would appreciate recommendations for another GUI compiler/IDE that could. Any help is appreciated. Thank you.
I want CodeBlocks to act like a Unix
compiler in that it overwrites..
First of all, C::B isn't a compiler -- it's an IDE. Saying you want C::B to act like a compiler makes no more sense then saying you want vim, emacs, or visual studio to 'act' like a compiler.
Second, you change the name of the final executable by right-clicking a project in your workspace. Goto properties->Build targets tab->select which build target you want to change. On the right side of this you'll see Output filename. Enter the executable filename the linker should output here. Alternatively, you can just navigate to the location of your existing executable and just rename it to something else.
And thirdly, chances are you're not even going to be checking back on this site so I'm probably just wasting my time giving an answer to your post.