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

Date:	July 21, 2011 / year-entry #176
Tags:	history
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20110721-00/?p=10093
Comments:	22
Summary:	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...

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)

Paul says:

July 21, 2011 at 7:10 am

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.
Bob says:

July 21, 2011 at 7:10 am

Securit3.dll. Claim it's l33t French.
J says:

July 21, 2011 at 7:26 am

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

July 21, 2011 at 7:35 am

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?
Josh Einstein says:

July 21, 2011 at 7:54 am

Maybe he thought 128 bit OS's would come before long filename support and planned ahead?
Maurits [MSFT] says:

July 21, 2011 at 8:22 am

Another alternative:

32-bit version: security.dll

16-bit version: security.16

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

July 21, 2011 at 9:01 am

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]
S says:

July 21, 2011 at 9:17 am

Maybe he was leet? The 3 is an E?
Troll says:

July 21, 2011 at 9:43 am

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.
Joshua says:

July 21, 2011 at 11:33 am

@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).
Troll says:

July 21, 2011 at 12:19 pm

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.
f0dder says:

July 21, 2011 at 1:12 pm

"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]
JK says:

July 21, 2011 at 2:14 pm

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.
Yuhong Bao says:

July 21, 2011 at 2:21 pm

"(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.
Yuhong Bao says:

July 21, 2011 at 2:29 pm

"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.
Adam Rosenfield says:

July 21, 2011 at 2:45 pm

@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.
Muzer says:

July 21, 2011 at 5:01 pm

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?
f0dder says:

July 21, 2011 at 3:43 pm

"[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 :)
SuperKoko says:

July 22, 2011 at 12:47 am

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.
640k says:

July 22, 2011 at 1:13 am

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

July 22, 2011 at 3:25 am

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.
Random832 says:

July 22, 2011 at 6:19 am

"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.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index