Since Windows 3.1, the moricons.dll file contains, well, more icons. What were these icons for?
Windows 3.0 added the ability to run MS-DOS programs in a window. One of the preinstalled program icons was called Windows Setup, and if you ran it and selected Set Up Applications, it offered to search your hard drive for existing MS-DOS applications and “help run them more easily in the Windows environment.” If you accepted this offer, it showed a list of recognized programs, and you could select which ones you wanted to set up.
The mechanism for recognizing programs was by searching for the names of well-known executables such as 123.EXE for Lotus 1-2-3. Sometimes, there were multiple programs that used the same executable name. For example, MAIL.EXE was used by PATHWORKS Mail for MS-DOS, cc:Mail for MS-DOS, and XcelleNet X/Mail for MS-DOS. In that case, the program asked you, “Hey, like, I’m not sure which program this is. Can you tell me if it’s any of these guys?”
Once it identified a program (possibly with help from you), it created a PIF file that described an MS-DOS configuration that worked best for that program, created a Program Manager group called Non-Windows Applications (if one didn’t already exist), and created an icon in the Non-Windows Applications group which used the PIF file to launch that program.
In Windows 3.0, the icon for the program was just a plain gray icon that said “DOS”.
In Windows 3.1, Set Up Applications gained a feature: In addition to setting up the PIF file, it also set an icon in Program Manager that represented the program. When you clicked it, it still ran as an MS-DOS program, but at least the icon was prettier.
Initially, these icons were placed in PROGMAN.EXE, but as the number of icons grew, it became clear that they needed their own home instead of squatting inside the Program Manager binary. So the icons started getting added to a DLL called MORICONS.DLL because, well, they were more icons.
This MORICONS.DLL icon library has carried forward ever since. Windows itself created those Program Manager icons, and those Program Manager icons turned into shortcut files in Windows 95, and those shortcut files would then migrate forward as you upgraded Windows. In theory, the compatibility chain could have been abandoned with the introduction of 64-bit Windows since there was no upgrade path from 32-bit Windows to 64-bit Windows (clean installs only), and because 64-bit Windows didn’t support MS-DOS programs any more, so you couldn’t reinstall them onto your 64-bit Windows system.
I suspect this cleanup didn’t happen because the focus of the 64-bit port was bringing Windows forward to 64-bit, and most of the porting was mechanical: You could port a large chunk of code without even understanding what it did. The focus was not “looking for old 32-bit code that we can delete.”¹
Furthermore, the entire DLL was only 12 kilobytes, and it didn’t pose a security risk,² and there was a compatibility risk that somebody was still using those old-timey icons for their shortcuts. Better to let sleeping dogs lie and eat the 12 kilobytes.
Next time, we’ll take a peek inside progman.exe and moricons.dll and enjoy the old-timey icons.
¹ Not that deletion didn’t happen, but the deletion of 32-bit code was done when the mechanical porting was not good enough to get the code running. At that point, you had to make an engineering decision whether the effort spent reverse-engineering and debugging the 32-bit code was worth the benefit of having a 64-bit version available.
² Unless you consider “these icons are so ugly that if an attacker could get the icon to be displayed, it will cause lasting mental pain and anguish to everybody who sees it” to be a security risk.
It’s a shame there was no music by Ennio Morricone embedded into moricons.dll! 🙂
Glad to see some new stuff about old DOS/Windows. Frankly speaking, I’m very tired of C++-related posts: no fun, no additional knowledge that could be of use for me, lots of strange-looking code pieces like if it couldn’t be written in a more natural manner. Historical and PL-agnostic stuff is way better.
I, for one, appreciate your commitment to “PIF file.”
I just realized recent builds of Windows don’t have a 32-bit version. It appears the last version of 32-bit Windows is Windows 10 IoT Enterprise LTSC 2021. If that’s correct, PIF will finally cease to be supported on 13 Jan 2032…
I miss CARDS.DLL and wonder why it didn’t make the cut when other legacy stuff did. It was a pretty great resource if you needed to display a deck of cards!
These icons are great, I did not realize they had more purpose than just eye candy. I will surely try that feature next time I run Windows 3.1!
This brings back memories. One of my first Windows programs was a memory game where you click on tiles and they briefly reveal what’s underneath, and stay open or close back again depending on whether the two last clicks revealed matching images.
I was never a great artist and image-generating LLMs were not a thing for the next 30 years, so the program just used icons from moricons.dll.
This is the real answer, imho — the existence of these icon resources became part of the “logical interface” of Windows. Removing them would save 12 kb but risk breaking countless apps.
This reminds me of “When programs assume that the system will never change, episode 1” (and redux). In a recent article, “Top 11 things you can do to make your app great on Windows 11”, section “9. Use beautiful Iconography & Typography” mentions:
> File type icons are updated. If your app is using icons in imageres.dll or shell32.dll, then icons will be updated automatically. Otherwise, a manual style update might be needed.
It appears Microsoft’s position on “fishing system resources” has changed, at least imageres.dll and shell32.dll icons should always be kept?