views:

343

answers:

10

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)?

+16  A: 

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.

Carl Norum
And even before text displays were mainstream. There's a reason printf is printf and not displayf :)
Cogwheel - Matthew Orlando
Actually, `fopen` *is* written directly in terms of `CreateFile`. If you follow it's implementation through, it eventually calls `CreateFile` in open.c of the CRT source (included with Visual Studio).
Dean Harding
My comment above obviously applies to Windows only. The point of using `fopen` is that it's available on any C implementation and uses whatever the "native" method for opening files happens to be on that platform... on Windows it's `CreateFile`, on Linux it's `open`, etc...
Dean Harding
@Dean, thanks for the information about `CreateFile`; I haven't ever written a Windows API program, so I was just guessing.
Carl Norum
Deans second comment clarified the relationship, I should use the WINAPI as much as possible for compatibility and robustness.
xaler7
And kernel32!CreateFile calls ntdll!NtCreateFile, which is the actual kernel syscall (which eventually calls IoCreateFile in the IO Manager part of the kernel).
Chris Smith
+10  A: 

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.

Cogwheel - Matthew Orlando
+5  A: 

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.

bshields
+1  A: 

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).

Romain Hippeau
+4  A: 

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.

Jerry Coffin
+2  A: 

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.
S.Lott
After reading your response it seems my definition of portable might be off. See comment at the top about portability.
xaler7
Thanks for telling me to edit the question directly.
xaler7
I don't think the source code to these is a trade secret. Microsoft ships fopen.c with Visual Studio.
Ken
I think the source code to Windows is a trade secret.
S.Lott
What I said is a rephrasing of Dean 'codeka' Harding's second comment above, perhaps he said it in a less confusing way than I did.
xaler7
A: 

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

Mehdei
+1  A: 

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.

Windows programmer
+1  A: 

the WINAPI provides an interface that developers in C can use in order to use the WINAPI functionality. C++ programs can also use it.

Anon
A: 

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.

Evan