Why is secur32.dll called secur32.dll and not secure32.dll?


Many years ago, in a discussion of why you shouldn't name your DLL "security.dll", I dug a bit into the history behind the DLL. Here are some other useless tidbits about that file.

Originally, there were two DLLs called security.dll. One was the 32-bit version and one was the 16-bit version. They could coexist because the 32-bit version was in the system32 directory and the 16-bit version was in the system directory.

And then Windows 95 showed up and screwed up everything.

Windows 95 did not have separate system32 and system directories. All the system files, both 16-bit and 32-bit, were lumped together in a single system directory. When the Security Support Provider Interface was ported to Windows 95, this created a problem, for it would require two files in the same directory to have the same name. Since the 16-bit version had seniority (because your Windows 95 installation may have been an upgrade install over Windows 3.1, which would have been the 16-bit version), it was the 32-bit version that had to be renamed.

Okay, so why secur32.dll? Well, security32.dll was too long, since it exceeded the classic 8.3 limit, and Windows NT supported being run on FAT volumes (which necessarily did not support long file names, since long file names on FAT didn't exist until Windows 95). Okay, but why secur32.dll instead of secure32.dll, which still fits inside the 8.3 constraints?

Nobody knows for sure any more; the person who chose the name left Microsoft a long time ago. Perhaps because secur32.dll looked better than securi32.dll. Maybe he couldn't count.

Comments (22)
  1. Paul says:

    Maybe due to the security.dll clash?

    "You want your app's 32bit security DLL to be called secure32.dll? Fine, We'll sit out of its way."

    As a guess.

  2. Bob says:

    Securit3.dll. Claim it's l33t French.

  3. J says:

    Reminds me of the "creat" and "umount" fiascos in Unix-land.

  4. NB says:

    Maybe because secure32.dll would give the wrong impression – hint that it's a "secure" DLL rather than a DLL related to the security provider?

  5. Josh Einstein says:

    Maybe he thought 128 bit OS's would come before long filename support and planned ahead?

  6. Another alternative:

    32-bit version: security.dll

    16-bit version: security.16

    [And that would show up in the import table how? -Raymond]
  7. Nick says:

    Why are you assuming it was a he? Women make mistakes too, just don't tell my wife I said that. ;)

    [Because it was a "he". (Next time, I'll write gender-neutrally, like I usually do. Though that won't stop people from assuming it was a guy. In at least one of the linked stories, the subject is in fact female. I won't say which one(s), so don't try guessing.) -Raymond]
  8. S says:

    Maybe he was leet? The 3 is an E?

  9. Troll says:

    Why were games in Windows 9x never 32-bit binaries? Even after Windows NT was shipping with 32-bit binaries, Charmap, Clipbrd, Dialer, Defrag, Scandskw and the games always remained 16-bit even in Windows Me.

  10. Joshua says:

    @Troll: because in Win9x, 16 bit was in fact king and if you were going to do low-level junk you had an easier time being 16 bit.

    In particular I name Scandskw and Defrag as needing to be 16 bit because 16 bit can do direct disk IO while 32 bit can't.

    Also, on Win9x, a 16 bit app can suspend the multitasking environment. I think this is the reason for the special Ctrl-alt-del handler in Win9x that overrode thread priority (or maybe it simply used it).

  11. Troll says:

    In Windows 9x, ScanDskw.exe is just a wrapper for shell functions. Some guy even created a 32-bit ScanDskw which can replace 16-bit Scandskw and runs just fine.

  12. f0dder says:

    "32-bit version: security.dll, 16-bit version: security.16

    [And that would show up in the import table how? -Raymond]"

    As security.dll and security.16? Just like some PEs have WINSPOOL.DRV referenced in the import table? :)

    [News flash: 16-bit apps aren't PE format. -Raymond]
  13. JK says:

    letter "i" is sometimes mis-read as number "1" or letter "l" in a small monitor. This is the reason why license plate does not allow letter "i" and "l" to avoid confusion.

  14. Yuhong Bao says:

    "(which necessarily did not support long file names, since long file names on FAT didn't exist until Windows 95)"

    Actually it was NT 3.5 that first supported LFNs on FAT.

  15. Yuhong Bao says:

    "In particular I name Scandskw and Defrag as needing to be 16 bit because 16 bit can do direct disk IO while 32 bit can't."

    Well, I think VWIN32 had a documented DeviceIoControl interface to call the necessary DOS calls for disk IO.

    "Also, on Win9x, a 16 bit app can suspend the multitasking environment."

    Yep, I know, the infamous Win16Mutex.

  16. Adam Rosenfield says:

    @JK: That's probably determined on a state-by-state basis.  There's a car with NH plates II1I11 (or maybe it was I11II1, I can't remember exactly) that I often walk by.  I'm betting that the owner intentionally chose the combination of I's and 1's that was most likely to be written down incorrectly by a policeman (or anyone else in the chain) in order to maximize the chance of avoiding a ticket.

  17. Muzer says:

    I'm going to bite here – so why didn't they just have separate system/system32 directories in Win9x like they did in earlier and later versions of Windows, if it caused this problem, and presumably quite a few more problems?

  18. f0dder says:

    "[News flash: 16-bit apps aren't PE format. -Raymond]"

    My bad, had momentarily forgotten about NE; thanks for the history reminder :)

    I can't be bothered looking up the reference nor a 16-bit capable OS, but my hunch is it imports by module name without extension.

    So, it *should* have been possible to do "security.dll" for 16-bit Windows, "security.32" for 32-bit. Whether it would have been a good idea is another discussion entirely :)

  19. SuperKoko says:

    Also, on Win9x, a 16 bit app can suspend the multitasking environment.

    A 16 bit app can only suspend all 16 bit processes, including the GDI/USER stuff.

    Consequently, an application doing 32 bits stuff (e.g. CreateFile/WriteFile) but no GUI interaction, won't be stopped by a 16 bits application.

  20. 640k says:

    Are the 64-bit security dll called secur32.dll or security.dll?

  21. Neil says:

    Other things 16-bit apps could do (more) easily:

    1. Read the free system resources. Someone had this app which happened to display the free system resources for some reason. Obviously the 16-bit version displayed bogus results on NT, but nobody cared about that. When he wanted to port his app to 32-bit he wanted to link to RSRC32.DLL so that he could continue to display the free system resources on Windows 9x, it being more popular than NT4. So I wrote him a version of RSRC32.DLL to install on Windows NT so that their 32-bit app could link to it and get the same bogus results as the old 16-bit version of the app used to get.

    2. Play sounds on the internal beeper. So for instance Minesweeper could play its little scale when you won.

  22. Random832 says:

    "A 16 bit app can only suspend all 16 bit processes, including the GDI/USER stuff. Consequently, an application doing 32 bits stuff (e.g. CreateFile/WriteFile) but no GUI interaction, won't be stopped by a 16 bits application."

    How will it get scheduled?

    [Um, pre-emptively. -Raymond]

Comments are closed.