The Old Joel on Software Forum: Part 4 (of 5) - C-runtime, what it refers to in Win32?

C-runtime, what it refers to in Win32?

I'm reading some Win32 book and I see the term "C runtime" a lot.

I see that there are certain type of functions, like file manipulation.

Does this map to Win32 functions? Or Win32 maps these? Or are these a separate animal?

Do somebody has a nice, clean intro text about this topic?

Thanks,
P"

P"
Friday, February 6, 2004

CRTDLL.DLL

The library that contain all of the standard c lib functions like malloc(), strlen(), fget(), etc....

It's usually linked by default if you include and .h file that uses it in Visual Studio.

Andy in Austin
Friday, February 6, 2004

Oh, and if you have the Enterprise Edition of Dev Studio, you can select to install the source for all this stuff.

Andy in Austin
Friday, February 6, 2004

"Does this map to Win32 functions? Or Win32 maps these? Or are these a separate animal?"

Generally speaking, the implementation of a C runtime will use the underlying OS facilities. So, a call to malloc() will likely eventually use memory from a heap that was created with a function like VirtualAlloc() in Win32.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, February 6, 2004

The C-runtime is the library provided by your compiler vendor. Any C text should cover the basics of this.

On Windows the Win32 API is the interface exposed by the operating system. The compiler vendor will have written their C-runtime against the Win32 API.

On Linux the library will be written against the system calls exposed by that operating system, but will still present the same calls to you as a C programmer.

Rob Walker
Friday, February 6, 2004

Wow, what a coincidence. I've just spent my day researching this exact topic. Mostly in reference to File i/o.

So fread calls ReadFile within Windows. Still then, would there be a performance hit in choosing one over the other?

I figure using ReadFilea, as its the source API, is more optimal.

sedwo
Friday, February 6, 2004

If you know what you are doing then going after the Win32 API directly is going to be more efficient -- but I think it would be challenging to come up with a scenario where you could actual spot the difference.

If you want to really focus on performance then make sure you build using the unicode API (ReadFileW, etc). If you define UNICODE in your build (before the windows headers) then ReadFile will just be a macro for ReadFileW. The operating system uses unicode internally.

Another thing to watch out for in using the Win32 API over the C runtime is how line feeds are handled. If you just use fopen(...) on a file and don't specify that it should be treated as binary, then the library will try to do some automatic conversions. Check the documentation for details, but this will add a small performance hit.

Rob Walker
Friday, February 6, 2004

ReadFile reads a chunk of bytes from a handle. Ask for 1 byte, a request goes down to the OS (and through the drivers, etc.) for 1 byte.

fopen does buffering on its underlying stream. So, the first time you ask for 1 byte, it'll read 512 bytes (or whatever the default buffer size is). The second time, it'll just return the next byte out of the buffer, not request it from the OS.

fopen provides convenience. If you naturally process your data in blocks, it's just overhead. But if you go char by char (or line by line) the buffering provided by fopen can help.

The moral of the story is: measure, don't guess, about performance.

-Chris

P.S. This gets even more complicated by the fact that the OS does it's own buffering too. However, a call to ReadFile still involves a switch into the kernel even if the data's coming out of a buffer, so it can still be expensive.

Chris Tavares
Friday, February 6, 2004