Author Topic: Opening file with MSVCR DLL instead of direct syscalls  (Read 9099 times)

Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Opening file with MSVCR DLL instead of direct syscalls
« on: April 04, 2013, 05:23:03 AM »
Greetings, I was wondering how the C and C++ libraries open files so I looked in the includes that come with MS Visual C++ and also the includes that come with Bloodshed DevC++ and when u go deep enough, it turns out they don't actually open files at all. They just have function declarations for external functions in libraries like MSVCR DLL.

Why is that? Is it only "allowed" to go through MSVCR DLL to interact with the filesystem?  If that's the case, then why do syscalls exist to interact with the filesystem?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #1 on: April 04, 2013, 10:39:59 AM »
I don't know how C++ and Windows do it, but I imagine that everything has to go through a low level routine for any actual file access. Lower level than msvcr(t?).dll, I would have thought. Is there an ntfs.dll? If so, that's where I would expect the "real work" to be done. I'm not sure what you mean by "direct syscalls" in a Windows context...

Best,
Frank


Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #2 on: April 04, 2013, 01:19:51 PM »
Frank, by direct syscalls I mean there are syscalls for opening files, read, write, close, etc. I've seen this done in assembly, but not sure if was for Win or Linux. Sorry I am on a mobile phone right now and can't give you a link, but I could give the link later today.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #3 on: April 04, 2013, 08:11:30 PM »
Oh, in Linux, yeah. Strictly speaking, there are "syscalls" underlying Windows, too, but we're generally not allowed to touch 'em. Take away the "MS" and we've got a C library, too. The C library provides open/read/write/close and also provides fopen/fread/fwrite/fclose. The latter group are "buffered I/O" - they allocate a buffer and manage it, as well as accessing the file. This makes a big difference, for example, if we were reading a file a byte at a time. "read()", which is pretty much "sys_read", AFAIK, we would read a sector (smallest amount we can actually read), and fetch a byte from it. "read()" another byte, and we read a sector again, and fetch a byte from it. "fread()" only actually reads from the disk the first time, and when the buffer is exhausted - subsequent "fread()"s just fetch a byte from the buffer until we actually need to "read()" some more sectors. This can make a C program much faster than a naive asm program! Of course, if we're aware of this, we "read()" or "sys_read" a bufferfull at a time and just fetch bytes from it - just like "fread()" is doing for us.

As I recall when I was trying to learn C, they told us to just use the "f" versions and forget the "low level" calls... but I'm pretty sure the "high level" routines use the "low level" routines, and ultimately syscalls, to do the actual work. So I guess you could say that the syscalls exist to enable the library calls, rather than the other way around...

Best,
Frank


Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #4 on: April 04, 2013, 09:27:58 PM »
Frank, thanks for that detailed explaination. One question I have is about this part:

Quote
Take away the "MS" and we've got a C library, too. The C library provides open/read/write/close and also provides...

Does that mean that I can dig into the code of the C library functions like the "open()" or "fopen()" and see all the low level work in C code?  Or will I just run into a call to a to an extern assembly?

Basically I am interested if this type of really low level stuff like direct syscalls can be done from C itself, or if you can only do that stuff by descending into assembly.
« Last Edit: April 04, 2013, 11:04:16 PM by hhh3h »

Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #5 on: April 07, 2013, 08:30:35 PM »
Bump and btw, yes it is "MSVCRT".  I was using my phone when I typed this thread so I remembered it incorrectly.  Thanks

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #6 on: April 08, 2013, 03:51:02 PM »
Does that mean that I can dig into the code of the C library functions like the "open()" or "fopen()" and see all the low level work in C code?  Or will I just run into a call to a to an extern assembly?

You will eventually encounter external calls to the kernel modules.
MSVCRT ( the Microsoft Visual C RunTime ) mostly provides a layer between the kernel and your C program.

Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #7 on: April 08, 2013, 05:37:32 PM »
Hmm I think what would clear this up in my mind is if I knew whether C code can by itself perform those system calls.  If not, does that mean that MSVCRT was written in assembly?

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #8 on: April 09, 2013, 12:37:21 AM »
You absolutely can duplicate the functionality of that library.
However, the better questions is: why would you?

That library was built with mostly C code with very little assembly.

If you're programming Windows in C you want to use it.  If you're programming Windows in assembly you can ignore it.  In that case you will want to look at the Windows SDK for function call syntax when making calls into the User32, Kernel32, or or any other System32 DLLs.

Offline hhh3h

  • Jr. Member
  • *
  • Posts: 41
Re: Opening file with MSVCR DLL instead of direct syscalls
« Reply #9 on: April 09, 2013, 04:07:04 AM »
Thanks Rob, that helps a lot.