The gradual erosion of the SEM_NOOPENFILEERRORBOX error mode

The SEM_NO­OPEN­FILE­ERROR­BOX flag has a long history.

It goes back to 16-bit Windows and the way modules were loaded from floppy disks. If the loader could not find the file it needed, it prompted you to insert the disk and gave you the option to retry or cancel. The SEM_NO­OPEN­FILE­ERROR­BOX flag lets you disable the prompt and force the system to act as if you had selected Cancel.

The 16-bit kernel also exported a function called Open­File that lets you access the routine in the module loader that tries to open a file and prompts for retries if the file isn't found. Therefore, the SEM_NO­OPEN­FILE­ERROR­BOX flag controlled the Open­File function, too.

Forward to 32-bit Windows NT. The Windows NT module loader doesn't work anything at all like the 16-bit module loader. Memory management is page-based rather than segment based. Images are memory-mapped and operate on page faults rather than being manually loaded from the disk and operating on segment faults (or worse, segment reload thunks).

This means that the old model of prompting the user to reinsert the floppy disk makes no sense. There is never any prompting for failed module loads. The SEM_NO­OPEN­FILE­ERROR­BOX flag has no effect for modules, which means that you won't see any error boxes from Load­Library on Windows NT. (On Windows 95, if the DLL you were trying to load had a chain of dependencies that led to a missing 16-bit DLL, then you still got the error box from the 16-bit loader.)

This means that today, the SEM_NO­OPEN­FILE­ERROR­BOX flag has no effect.

Well, almost.

Remember that Open­File function? The one that let you open a file using the same retry logic as the 16-bit module loader? The function was ported to 32-bit Windows, but of course it doesn't actually use the 16-bit module loader. It just replicates the behavior of the 16-bit module loader.

Including the error prompt if the file cannot be found.

So that's where we are today. The SEM_NO­OPEN­FILE­ERROR­BOX flag has been eroded away. The only place that still respects the flag is the old Open­File function, a function you probably didn't even realize existed, and which exists only for backward compatibility with 16-bit programs.

Bonus chatter: I submitted a documentation change request to MSDN to clarify this. We'll see which happens first: This article gets posted or the MSDN change request gets processed.

Comments (6)
  1. Kyle S. says:

    So who won? MSDN or Raymond?

  2. Rutger says:

    You won :)

  3. Tihiy says:

    AFAIK this is still required when you access unmounted drives (ejected CDs, card readers, etc). Without it, you’ll see ‘hard error’ message box with dreaded ‘No disk in drive’ – Abort, Retry, Ignore. No?

    1. cheong00 says:

      From the way OpenFile() is documented, I think you have to pass OF_PROMPT to show a dialog with “retry” and “cancel” only.

    2. Yuhong Bao says:

      I think that might be SEM_FAILCRITICALERRORS

  4. Neil says:

    Goes to show how much I know… I thought OpenFile was the preferred way to open a file in 16-bit Windows.

Comments are closed.

Skip to main content