How can one get a HFILE?

I know CreateFile() and OpenFile() can create HFILE.

Is there other APIs can create HFILE?
LVL 1
fengtao2000Asked:
Who is Participating?
 
robpittConnect With a Mentor Commented:
ReadFile works with some objects that are not files. In particular ReadFile works with handles to consoles, pipes, sockets and mailslots (maybe more).
0
 
jhanceCommented:
What do you mean?  
0
 
fengtao2000Author Commented:
I found some programs don't call CreateFile() to get HFILE, but it can call ReadFile() successfully.

So I want to know which APIs can get a HFILE, or do the job same with CreateFile().
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

 
jhanceCommented:
How do you know that they don't call CreateFile() or OpenFile()?
0
 
fengtao2000Author Commented:
I intercept CreateFileA() and ReadFileA(), and log all the calls.

The app is ansi, so there is no unicode APIs call.

I log many normal CreateFile(), but there are some ReadFile() calls, and the HFILE is not returned by CreateFile(), I don't know where they come from.

There must be another way to do the same job as CreateFile().

Who know about it?
0
 
pjknibbsCommented:
The applications in question might be using the OpenFile() function--however, I wouldn't suggest using this yourself because it is provided purely for backward compatibility with 16-bit Windows.
0
 
PavlikConnect With a Mentor Commented:
You can use ReadFile with socket handles for example. Or with pipes of any sort. (for example inherited from parent process). Or with handles created by CreateFileMapping().
0
 
AxterCommented:
>>I found some programs don't call CreateFile() to get
>>HFILE, but it can call ReadFile() successfully.

If the program is using MFC code, then it's probably calling CreateFile indirectly, via CFile or a derive class from CFile.

CFile uses CreateFile, and it has an undocumented HFILE operator.
0
 
PavlikCommented:
Axter!!!
What are you talking about?
mfc\src\filecore.cpp (line 194):

HANDLE hFile = ::CreateFile(lpszFileName, dwAccess, dwShareMode, &sa, dwCreateFlag, FILE_ATTRIBUTE_NORMAL, NULL);

And what undocumented you have found here?

I think that's not the case.

0
 
AxterCommented:
Pavlik,
>>And what undocumented you have found here?

See the following:
C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\MFC\Include\AFX.H(1245): operator HFILE() const;

AND

C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\MFC\Include\AFX.INL(85):_AFX_INLINE CFile::operator HFILE() const

You'll notice that on the second line of source code, that the operator returns m_hFile class member.

This data member, happens to be given the value that is returned from CreateFile.

See the end of CFile::Open member function, and you'll see the following:
m_hFile = (HFILE)hFile;
0
 
AxterCommented:
Pavlik,
>>And what undocumented you have found here?
The CFile HFILE operator member function, is not documented in MSDN, or any other MS documents that I've come accross.
0
 
PavlikCommented:
And i don't understand what's wrong with it.
The type of hFile is HANDLE and therefore CFile::operator HFILE() will NEVER be called in the line like this:
m_hFile = (HFILE)hFile;

It is just conversion from (void*) to (int).

And even if something mystical was done with that handle. Who cares? Since initially this handle was obtained from CreateFile().

Don't think that the only thing that Microsoft does is making undocumented holes. Believe me, it's much harder to keep track of such holes than not to make and not to use them.

And this operator is very usual technique in the implementations of thin object oriented wrappers around non object oriented API. It allows to use object of CFile in the places, where HFILE is required.
0
 
AxterCommented:
>>and therefore CFile::operator HFILE() will NEVER be
>>called in the line like this:
>>m_hFile = (HFILE)hFile;

I never said it would.  I think you misunderstood my comments.

That line of code comes from the CFile::Open function.

The point of me posting that is that you said CFile doesn't use HFILE.  But it does.

The CFile::operator HFILE() function returns m_hFile.

m_hFile is given the value of hFile in the CFile::Open function.

hfile is initated to the value returned from CreateFile.

Now hfile variable is of HANDLE type.
And m_hFile variable is of UNIT type.
And of couse the operator HFILE() member function is returning an HFILE type.

So the MS's code casted a HANDLE type to an UNIT, then via the operator HFILE() member function, it's casting a UNIT type to an HFILE type.

>>Don't think that the only thing that Microsoft does is
>>making undocumented holes. Believe me, it's much
>>harder to keep track of such holes than not to make and
>>not to use them.

I'm not sure what your point is in all this, and what it has to do with the question, or the comments I posted.
 
The questioner asked specifically about CreateFile(), OpenFile(), and HFILE.

My original commented pointed out the MFC code uses these functions, and it has the HFILE operator in CFile class.

So even if you have an MFC application that is not directly calling CreateFile() and OpenFile(), it still would be called if CFile is used.
Furthermore, an HFILE type could be crated adn passed around via CFile since CFile has an HFILE operator.
0
 
PavlikCommented:
Oops.

Sorry Axter.
Looks like i didn't understand your very first comment.
As i thought, fengtao2000 hooks all the calls to CreateFile/ReadFile, not reads through some source code. My point is that if he logs actual calls to CreateFile he won't miss this call for MFC based app.
0
 
Answers2000Commented:
_lcreat
_lopen
APIs also return HFILE
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.