What happens if I don’t pass a pCreateExParams to CreateFile2?

The final pCreateExParams parameter to the CreateFile2 function is optional. What happens if I pass NULL?

If you pass NULL as the pCreateExParams parameter, then the function behaves as if you had passed a pointer to this structure:

 sizeof(defaultCreateExParameters), // dwSize
 0, // dwFileAttributes
 0, // dwFileFlags
 0, // dwSecurityQosFlags
 NULL, // lpSecurityAttributes
 NULL, // hTemplateFile
Comments (10)
  1. Koro says:

    I still don't understand the point of taking the last few parameters of CreateFile and stuffing them in a struct. It's not like the new API is offering any new functionality.

  2. skSdnW says:

    CreateFile2 and CopyFile2 are on the WinRT supported list and GetProcAddress is not, this means all new features have to be added in the struct parameter so apps can use new features while staying Win8 compatible.

  3. Dave Bacher says:


    In addition to what people are saying about forwards and backwards compatibility, think about this.

    This improves readability — instead of one routine with a parameter list stretching for multiple lines of code, you have some assign statements.  If you're reading it, instead of ( and a comma separated list — you have actual names.

    If you're doing a C++ class — say "SerializedStream" and "RandomAccessStream" — you can set up the structure generically in the base class, then in the derived class, you can manipulate it.  If you're using a component system (like COM, Unity3D or Sunburn for example), the components can reach into that structure and change it before the actual call.  In structured programming, you might be able to have primitives to encapsulate setting the structure up correctly as well.

  4. Cesar says:

    @Dave Bacher: you can also use a designated initializer instead of assign statements:


     .dwSize = sizeof(params),

     .dwFileAttributes = …


  5. Azarien says:

    @skSdnW I have a weird feeling that "staying Win8 compatible" is gonna be pointless pretty soon, as far as WinRT goes.

  6. skSdnW says:

    @Myria: Yes, that is very cute :) If MS will approve store apps that do this is a different question…

    @Azarien: I guess I should have said Win8 and any other system that only has CreateFile2 and not CreateFile3.

  7. Adam Rosenfield says:

    @Koro: From the documentation, it seems like the only new parameter in CREATEFILE2_EXTENDED_PARAMETERS is the dwSecurityQosFlags, so it does offer *some* modicum of new functionality of CreateFile.  Plus, now with the dwSize parameter, it's easily extendable in future versions of Windows without needing to create a new function CreateFile3.

  8. Myria says:

    @skSdnW: GetProcAddress is on the WinRT supported list — see its MSDN entry.  You just can't call GetModuleHandleExW to find kernel32.dll.  However, you *can* call VirtualQuery from WinRT applications!  Pass VirtualQuery to itself (*).  Cast the resulting AllocationBase to HMODULE — that's kernel32.dll's module handle — and pass it to GetProcAddress.

    (*) It's not a direct "forwarder" to another DLL, so this works.

  9. Gabe says:

    Adam Rosenfield: The dwSecurityQosFlags parameter isn't new either. CreateFile has SQOS combined with the bits in the dwFlagsAndAttributes parameter, while CreateFile2 just breaks it out.

  10. Anon says:


    I wouldn't worry much about that. You can write the worst garbage the world has ever seen, and MS will bend over backwards to support it for the rest of eternity.

Comments are closed.

Skip to main content