I think getch() is the most primitive input function of C, on which
getchar(),etc. are based. What may be happening is that getchar() uses getch() to take input, and keeps buffering it till getch() returns 26 (ascii for ctrl+z, which indicates the end of input in Windows) is encountered. It now senses that its the end of input and returns EOF.

>I think getch() is the most primitive input function
>of C, on which getchar(),etc. are based.

Such an implementation is certainly possible, but I haven't heard of one in the wild yet. Further, even if an implementation did exist that used getch as a primitive base for stdio, your statement is still wrong. Try again, and this time remember that getch is a non-standard library extension (on a select few compilers).

getch() returns 26 (ascii for ctrl+z, which indicates the end of input in Windows)

That's a very usual misconception. First of all, ctrl+z is only significant for text mode streams. Second, for text mode streams, ctrl+z is handled by the driver. It is the driver who encounters ctrl+z, and in response it closes the stream. An application would never read ctrl+z; it hits an end of file instead.
For a binary mode streams, ctrl+z is an ordinary character.

That's a very usual misconception. First of all, ctrl+z is only significant for text mode streams. Second, for text mode streams, ctrl+z is handled by the driver. It is the driver who encounters ctrl+z, and in response it closes the stream. An application would never read ctrl+z; it hits an end of file instead.
For a binary mode streams, ctrl+z is an ordinary character.

Thanks!

When we write this :

printf ("%d",getch());

and press ctrl+z, we get 26. This, then means that getch() is working on a binary stream, by what u said.

In contrast to it, getchar() must be working on a text stream, that's why the following condition is satisfied :

while ((a=getchar())!=EOF);

when we press ctrl+z.

One thing more, the driver is the device driver for the keyboard, na ?

Anyone what?
If you stop talking about getch() and other non-standard functions, we might be able to explain what happens.

One thing more, the driver is the device driver for the keyboard, na ?

No.
Open a binary editor. Create a file having "Hello^Zworld" in it. Save it as foo.txt. Now at the prompt type copy foo.txt bar.txt . At the next prompt type copy /b foo.txt baz.txt . Finally, with the same binary editor compare contents of bar.txt and baz.txt. Notice that the console was not involved.
The ^Z does signify the end of any text mode stream regardless of its origin. Yet again, the application will never see it. Instead, whoever feeds stream data to application closes it, the same way that whoever closes the binary mode stream when the stream data are exhausted.
It is important to understand, that all stdio functions (not just getchar) obey this protocol.

In contrast to it, getchar() must be working on a text stream, that's why the following condition is satisfied :

while ((a=getchar())!=EOF);

when we press ctrl+z.

getchar works on the stream in the very same mode the stream currently operates. It is just happens so that by default stdin is in the text mode. It is not a rocket science to reopen stdin in binary mode, after which getchar would happily return 26 on ^Z. It is also enlightening to printf ^Z, and see what happens to stdout.
It is important to understand, that all stdio functions (not just getchar) obey this protocol.

When we write this :

printf ("%d",getch());

and press ctrl+z, we get 26. This, then means that getch() is working on a binary stream, by what u said.

Again, no. getch is a totally different creature. Remember, it is declared in conio.h - which means it works directly with the console driver, hence bypassing the stdio mechanism completely. It does not care (in fact, it doesn't know) about the stream mode, because it does not work with streams.
Make a program with getch, and try to redirect something to it.

This question has already been answered. Start a new discussion instead.