I've recently started write C based DLLs on Microsoft's Visual Studio 2019 (as I am used to traditional C over C++) and some reason I can't seem to get it to compiled with any common C functions like printf(), fopen() etc. I've tried everything from including stdio but it keeps printing unresolved external symbol __stdio_common_vfprintf when I tried using the cstdio instead, it showed a bunch of errors, identifier "using" is undefined, I have never experienced this before as I used to write in C on Xcode. Please help me.
In case it helps my ultimate goal is to make a logger class that logs messages to a console window created by AllocConsole, so I'm trying to do it with stdout and printf().
heres a pic
Related
I am working on a legacy program written in C. It is a 16 bit program. I was able to open it into Visual Studio 2019 but when I tried to compile it is giving me an error "Cannot open source file "graph.h". Similar error I have received for "bios.h" and "sound.h". Is there any other header library I can replace to achieve same functionality of graph.h, bios.h and sound.h.
Assuming you mean graphics.h, bios.h and sound.h, these were MS DOS libaries provided by Borland in the year 1989. graphics.h specifically was used for the old Borland MS DOS graphics library "BGI". sound.h was made to activate the "PC speaker" buzzer, used to scare away carnivore dinosaurs. These libs don't exist outside old Borland DOS compilers.
To run this ancient crap, you need a MS DOS computer with Turbo C. Or an emulator that can simulate them. If you surf the internet, there's lots of strange people putting lots of effort into getting such emulators up and running on computers made this millennium.
I would however recommend to forget all about MS DOS programming, because there is absolutely nothing to learn from running this old stuff. You should study modern tools and libraries instead, the kind that are actually used in the real world.
I'm struggling with the Code::Blocks IDE when programming in C.
I use one custom library, named "main.h".
Yesterday, when I begun working on the library, the program compiled without errors. I even put some functions written on the library on my source file and it built and ran fine.
Today, when trying to recompile the whole project after some modifications, appeared the "undefined reference" error.
I searched it over on this site, I tried to follow the steps another user proposed but now, instead of the "undefined reference" error, appears the "cannot find -l[filename]".
I tried to collect information about this error on this site as well but, I understand, it's a OS problem and, apparently, never happened to other Code::Blocks users.
I use Windows 7 64 bit, in case this is the problem.
Can you please help me?
Try to put fullpath to library in build options of your project and be sure to put it in the right build scheme(Debug/Release) or both to be sure.
However it is quite strange name for library - "main.h". Is it "main.h.dll" or what? Maybe it is header file? If it is so and you put implementation of you functions in .h file and not in .c, some errors could occur.
I started programming in C and I have Visual Studio 2012.
I Write my program in Win32 ConsoleApplication and when I look in the Debug in my project there is an EXE file, and it work, but when i try to take it and run it from other computer that not runs Visual Studio it not working.
what i can do for it to work?
Thanks, Tomas.
go to the project properties and then: C/C++ -> Code Generation -> Runtime Library and then select the MT or MTD option depending in which configuration you are (for release MT and debug MTD)
The standard C functions like printf, fopen and strlen are delivered by the compiler vendor in a precompiled library and DLL. The default setting in projects is to not link all the standard functions directly into your program but keep them in an extra DLL and let your compiled program just use that DLL. On your machine with Visual Studio that DLL is present. On your other machine that DLL is not present.
There are two ways to solve that:
Look at the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist and copy the DLLs you need to the target machine.
You can go the project settings "C/C++"/"Code Generation" and change the setting "Runtime Library" to a value without "DLL" in its name (/MT and /MTD). Then the compiler directly links all the standard C functions into your program and you can just copy your program to the other machine.
The reason Microsoft prefers the DLL is that with the DLL you can have multiple small programs in a folder each using the same DLL. If linking statically you end up with multiple bigger programs where each program has built in the same functions.
I have a Visual Studio 2012 solution containing several projects, some in C and some in Fortran (using Intel Composer XE 2013). I frequently call from the Fortran code into the C code using the iso_c_binding utility, but I've noticed that I cannot debug the C code effectively. While debugging the Fortran code, I can view the contents of variables just fine, but if I step into the C code, suddenly they lose their sanity. Most variables just claim to be undefined; anything passed to the function will contain incorrect values (but it still does differentiate between pointers and objects/POD).
I can still step through the code; it seems to mostly follow the expected sequence of execution, but sometimes it does jump around a bit, which I'm familiar with from debugging compiler-optimized code on Linux with gdb.
I have a separate solution that also has C and Fortran projects. Both call into the same C project from the first solution, and in both cases, I can again debug successfully until I step into the C project from the first solution, at which point I have the same problems.
What am I doing wrong?
This is the standard bat signal for debugging code that was optimized. You'll need to rearrange you build settings so your Fortran code links to the non-optimized Debug build of the C code.
There are no breadcrumbs in your question as to how that went wrong in the first place. Start by checking which library is getting linked into your Fortran program and make sure that you can see distinct libraries generated for your C project in the Debug and Release builds. You need to link the one created by the Debug build.
All,
Need some help here. I am from a purely Java background and don't know much about C programming. Basically I need to write a C program (and create an executable) which would output the number of Free Bytes (RAM) on a Windows machine (XP/2008/7)
I have doing some research about it and found that there is a function called GlobalMemoryStatusEx and also a link on this:
http://msdn.microsoft.com/en-us/library/aa366589(v=vs.85).aspx
I have installed cygwin with gcc and the above program doesn't even compile for me. I know I am doing something stupid here..
$ gcc hello.c -o hello.exe
hello.c:3:19: error: tchar.h: No such file or directory
hello.c: In function `main':
hello.c:7: error: `MEMORYSTATUSEX' undeclared (first use in this function)
hello.c:7: error: (Each undeclared identifier is reported only once
hello.c:7: error: for each function it appears in.)
hello.c:7: error: expected `;' before `statex'
hello.c:9: error: `statex' undeclared (first use in this function)
Any help is very much appreciated!
As larsmans said, cygwin is not a Windows native compiler. In addition to MinGW, you might also consider Visual C++ 2010 Express.
Cygwin by default emulates a Unix API on Windows, rather than presenting the Windows API.
You may have more success with the MinGW package, which is GCC for Windows + Windows API.
If you are unfamiliar with C, and all you want to do is write this little program for Windows, you might find it easier to get started with the free Visual C++ Express. Chances are that MSDN examples will work out of the box.
Edit: You mention Java, but it is not totally clear whether the sole purpose of this C app is to be invoked from Java. In case it is, I thought I'd mention something called JNative. It appears to be a pure Java library that contains, among other things, a wrapper for GlobalMemoryStatusEx. Note that I found JNative via a Google search and haven't used it myself.
The function to which you refer is a Windows API function, which means you cannot call that function from cygwin, which is a POSIX emulation layer on top of Windows.
You have a few options at this point:
You could download download and install the Windows SDK, which includes the Visual Studio C/C++ compiler(s), for free.
You could download a copy of Visual C++ Express Edition for free.
If you are a student, you could get a full copy of Visual Studio 2010 from MSDNAA (provided by your University) or from DreamSpark.
You could purchase a full copy of Visual Studio.
You could download and install MinGW, which is the GCC compilers ported to Windows.
Note that all of the Microsoft compilers support the entire Win32 API. MinGW is limited in its handling of Unicode on Windows, it does not support COM (so if you want to call COM APIs it's a pain), and it doesn't include all of the headers included with the Windows SDK.
GCC is a great compiler, its just not all that great in terms of its Windows support.
The answers presented are correct, but I don't feel that they explain the problem properly.
Unix and Unix-like operating systems strive to conform to a standard API called POSIX. Windpws does not conform to POSIX. Cygwin was written as way to provide POSIX compliance on Windows. Thus, when you compile on Cygwin, you are compiling on a POSIX API, not a Windows API. The function you found on MSDN does not exist in POSIX. Threefore, you get compile errors.
MinGW is gcc ported to Windows. It is aware of Windows API's with the proper includes. Visual Studio's nmake is the same in this regard (provides access to the Win API).
To use cygwin gcc to compile programs using the Win32 API, you'll want the mingw-i686-headers package (which includes header files like tchar.h).
Then, you may also need to define some macros to enable newer APIs.