I have to design a C project that is supposed to be run on Linux. I am very used to design C projects on Windows using Visual Studio or DevC++. Is it feasible to design the project on Windows and then port the code to Linux. Is it possible to use Eclipse CDT for switching compile configurations from Windows to Linux. What should i do? What do you suggest me to do or search?
This is a broad question since we have no info on what you're trying to achieve.
Some guidelines I can share with the limited information provided: in my experience it is feasible to write code on Windows and then port it to Linux although you should expect some differences in the Microsoft compiler and gcc compilers used in Linux/Unix (usually the more a compiler is conformant to the standard, the more it "warns" or won't accept something fishy in your code).
If you're dealing with a large number of dependencies / headers / source structures your project could greatly benefit from using a tool like CMake to deal with all those issues (a meta-generator that can generate makefiles and/or visual studio solutions depending on your platform from the same set of sources).
Also notice that you should NOT use any platform-dependent API in order to render your code portable. If you really need to, make sure to #ifdef those code sections for the specific platform you're compiling your code on.
Finally, if you plan to use a GUI in your application (or even if you're not planning one you might still benefit from the various libraries included), you might use a portable framework like Qt but keep in mind that this would require isolating the C part of your application from the C++ one (Qt). As another choice of your preference, you might also use GTK+.
I have a project wherein i need to write an application for an USRP device. But the gnuradio software which i use to interact with the device driver and ultimately the hardware provides apis in c++ and python. I am comfortable programming in c and thus would like a way which would let me to call the apis from my c program.Is there a way in which i could do so? It would be a lifesaver.
C++ adds a lot to C, but doesn't take much away. Except for a few corner cases (which can be worked around) most valid C code is also valid C++ code, so you won't encounter many problems when you compile it as C++. Just write your whole project in a C style and only use C++ features where they are necessary to interface with the C++ API of gnuradio.
I'm in the process of teaching myself C (coming from Java). I appreciate the language a lot, and one of the main reasons I am learning it is so that I can utilize the JNI feature built into Java to write native code when necessary. My question is mainly about the Windows API. Can I use the functions and features of the API using just C?
Will the Windows API be compatible with pure C code or does it contain classes and such that can only be utilized by C++ code?
Also, if I compiled a shared library on a Windows machine as (lib.sl NOT lib.dll), would it work on another machine (Mac/Linux)?
The Windows API (aka Win32 API) is a pure C library.
No you cannot use a Windows shared library on another non-Windows machine unless there is a software that supports Windows ABI - such as Wine or ReactOS.
Win32 API like others have pointed out is pure C. It means, once you get a hold of it, you will know everything about how the Operating system works. It is the same case usually with other operating systems as well. If you are after MFC/COM+ or Java wrappers, it is quite the opposite even if you can build great programs.
I looked at some other questions on SO and its not clear if c is built on top of, under, or alongside the WINAPI. Like for example could someone write something in pure c that was able to open a window, or would they need to use the windows api?
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile) which makes me wonder if one is just a wrapper for the other. Does anyone know?
If windows is running; is a programmer forced to program using the windows api to get something running on it or can the programmer not use the windows api at all and directly access the hardware (ie. does the windows operating system protect access to the hardware)?
Which is more portable between different versions of windows of windows ce. The documentation I found (which has now changed) used to say that CreateFile only goes back to version 2.0 of windows ce (here: http://msdn.microsoft.com/en-us/library/ms959950.aspx -
Notice the note on the link at the very bottom that shows the supported version information has been changed). So what is one supposed to use for windows ce version 1? In other words is programming using c functions or the functions labeled WINAPI more likely to work on all versions of windows CE?
I read the following in a book about programming windows ce and it confused me, so all of the above questions can be understood better in context of making sense of the following:
Windows CE supports the most of the same file I/O functions found on Windows NT and Windows 98. The same Win32 API calls, such as CreateFile, ReadFile, WriteFile and CloseFile, are all supported. A Windows CE programmer must be aware of a few differences, however. First of all, the standard C file I/O functions, such as fopen, fread, and fprintf, aren't supported under Windows CE. Likewise, the old Win16 standards, _lread, _lwrite, and _llseek, aren't supported. This isn't really a huge problem because all of these functions can easily be implemented by wrapping the Windows CE file functions with a small amount of code.
My understanding of wrapping is that you have to have something to wrap, given how it appears that win16 and c library are not available is he stating to wrap the CreateFile function to make your own c-like version of fopen? (The only other thing I am aware of is assembly, and if that is what he was suggesting to wrap it wouldn't be written in such a casual manner.)
Given the above, what is the dependency relationship between c language (syntax, data structures, flow control), the c function library (ex. fopen), and the windows api (ex. CreateFile)?
C existed long before Windows did. The Windows API is a bunch of libraries written in C. It may or may not be possible to duplicate its functionality yourself, depending on what Microsoft has documented or made available through the API. At some level it is likely that fopen() and CreateFile() each call the same or a similar operating system service, but it's unlikely that one is a strict wrapper for the other. It would probably be difficult to bypass the Windows API to access the hardware directly, but anything is possible given enough time and programming effort.
C doesn't know anything about GUIs, and VERY little about operating systems at all. Anything you do graphics-wise in C is through the use of libraries, of which the win32 api is an example.
The windows API is implemented in the C programming language. Functionality provided by the C standard libraries, such as fopen, is portable because it is compiled down to the appropriate assembly code for different architectures by different compilers. Windows API functions such as CreateFile only work on machines running Windows and are therefore not portable.
In theory it's possible to write C that talks directly to the hardware. Back in the days of MS-DOS (for one example) quite a few of us did on a fairly regular basis (since MS-DOS simply didn't provide what we needed). Edit: On some small embedded systems, it's still quite commonplace, but on typical desktop systems and such this has mostly disappeared.
Two things have changed. First, modern systems such as Linux and Windows are much more complete, so there's a lot less need to deal directly with the hardware. Second, most systems now run in protected mode, so normal user code can't talk directly to the hardware -- it has to go through some sort of device driver.
Yes, most of the C library uses the underlying OS so (for example) on Windows, fopen and fwrite will eventually call CreateFile and WriteFile, but on Linux they'll eventually call open and write instead.
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile)
Not surprising. They do similar things.
[is] one is just a wrapper for the other? Does anyone know?
You can't find out because the source code is owned and kept as a trade secret.
It doesn't matter which is more "fundamental". You use the windows API from a windows program. You use C API's from C programs.
Notice that it doesn't matter. You can use C API's or Windows API's intermixed.
If windows is running; is someone forced to use the windows api to get something running on it or can they bypass windows entirely and directly access the hardware?
"Directly access the hardware"? What does that mean? If windows is running, then.... well... Windows is running. Windows mediates your access to the hardware.
Use bootcamp or GRUB or some other bootloader to bypass Windows and have "direct access to the hardware".
If they can, is it possible to damage the hardware if you don't know what your doing?
What does this mean? Are you asking if you can "damage" some rotating media (i.e., disks) by misusing their drivers? You can corrupt your hard disk no matter what OS you're running or not running. A privileged account and dumb software can write bad data on a disk. Does that count as "damage"?
Which is more portable?
What does that mean? To another Windows computer? To a computer not running Windows? What are you asking about? Please clarify your question to define what you mean by "portable".
between different versions of windows
Since different Windows are mutually incompatible, I generally suggest using only the POSIX standard libraries and avoiding all Windows API's.
However, some Windows variants (e.g. Windows mobile for phone vs. Windows "Server") are essentially totally incompatible. There is very little reason for any piece of software to run on both OS's. Portability doesn't much matter. Why try to run a phone app on a server?
Edit
So theres the c language on the bottom (closest to the hardware), then the windows API next, then the C library on top of the Windows API?
This doesn't make sense. You're mixing up two unrelated things. The "language" and the "libraries" have little to do with each other.
Also, the API is not the operating system. So by using Windows "API" all the time, you're making this more confusing than it needs to be.
Here's a way to look at this.
The Windows Operating System has several API's. There are underlying function libraries that are not part of the application interface. They're "internal".
It has a native Windows API. Callable from C.
It has a POSIX API. Callable from C. In some cases, the Posix API generally uses the Windows API.
Most operating systems, including Windows are written in C (and or assembler). The Library is then modified for each operating system to do the basic stuff. (Sockets, Files, Memory, etc ...).
The WINAPI is just a bunch of libraries (written in C and/or Assembler) that allow access to functionality within the OS.
It is not Windows related, after you changed your question, I think what you are trying to understand is the bootstrapping of an OS (Windows or other).
The book Operating Systems Design and implementation discusses the implementation of Minix (Which Linux is based on).
the WINAPI provides an interface that developers in C can use in order to use the WINAPI functionality. C++ programs can also use it.
Operating systems such as Windows contain WINAPI libraries that provide access to some operating system functionality and sometimes contact with Hardware, these libraries are written in C
Carl Norum pointed out that C existed long before Windows, but don't forget that the Windows API kind of started with the MS-DOS API, which kind of started with the CP/M API. C only existed a short time before CP/M.
Lots of answers seem to imply that the Windows API is built on C, but that seems doubtful too. __stdcall is a synonym for PASCAL, which was a keyword in Microsoft's C compilers because the Windows API was built on Pascal. __cdecl is the default for function calls in C and C++ programs compiled by Visual Studio but it doesn't work on calls to APIs.
The relationship between C and the Windows API is that they are capable of working with each other.
As a fun note, you can really get a handle on the 'power' of the Windows API by taking a look at AutoIt http://www.autoitscript.com/autoit3/. AutoIt is a great little scripting language that can create GUIs, run command line apps, manipulate windows and processes, etc. Yes, it does File I/O and networking.
The published code for Palm OS applications doesn't include standard headers, but instead uses Palm OS APIs for things like StrCopy and MemMove. Can I use standard headers and functions or do I need to convert my code to use the Palm OS versions?
From a program size point of view its better to use the Palm OS API whenever possible, since that means you don't have to include the code from the library in the generated 'executable'. If you use functions from the compiler provided libraries the code of that functions will be added to each of your programs increasing their sizes.
It depends on the compiler and what version of the tools you're using. In general, if you can use Palm OS APIs, you'll probably work better on the platform, but both CodeWarrior and prc-tools had some library functions implemented.
In CW for Palm OS V9, there's a pretty full version of the Metrowerks Standard Library (MSL). Most of MSL C++ is there giving you access to STL and other constructs. On the C front, you've got most of the standard C headers for memory management and string functions. However, it omits implementations for locales, math, signals, and standard I/O.
To use the library, you need to make sure you link with the MSL C/C++ libraries. This can be set when you create your project in the wizard or added later by modifying the access paths and adding the appropriate static libraries for your targets.