Why is Rundll32 called Rundll32 and not just Rundll?


There is an oft-abused program named rundll32.exe. Why does its name end in 32? Why not just call it rundll.exe? (I will for the moment ignore the rude behavior of calling people stupid under the guise of asking a question.)

Because there needed to be a way to distinguish the 16-bit version from the 32-bit version.

Windows 95 had both rundll.exe (the 16-bit version) and rundll32.exe (the 32-bit version). Of course, with the gradual death of support for 16-bit Windows, the 16-bit rundll.exe is now just a footnote in history, leaving just the 32-bit version.

But why did the two have to have different names? Why not just use the same name (rundll.exe) for both, putting the 16-bit version in the 16-bit system directory and the 32-bit version in the 32-bit system directory?

Because Windows 95 didn’t have separate 16-bit and 32-bit system directories. There was just one system directory called SYSTEM and everything hung out there, both 16-bit and 32-bit, like one big happy family.

Well, maybe not a happy family.

At any rate, when 64-bit Windows was introduced, the plan was not to do things the crazy mishmash way and instead separate the 32-bit files into one directory and the 64-bit files into a different directory. That way, no files needed to be renamed, and your batch file that ran rundll32.exe with some goofy command line still worked, even on 64-bit Windows.

Comments (35)
  1. Joshua says:

    This is just one of those things. No better design avoids it. Oh well.

  2. Nick says:

    Except its still called rundll32 even 64-bit so its still wrong LOL.

    /snark

    :) :)

  3. Karellen says:

    @Nick – Ah, thanks! I was wondering about Raymond's "your batch file that ran rundll32.exe with some goofy command line still worked" comment, because I was thinking that surely rundll32.exe would still be there on 64-bit windows, because 64-bit windows includes 32-bit components by default, like 32-bit rundll32.exe.

    The idea that he was talking about a 64-bit version of rundll32.exe didn't even occur to me. So I take it that the 64-bit rundll32.exe lives in the system32 directory, while the 32-bit version lives in the syswow64 directory?

    (Definitely no crazy mishmashes there. Nope.)

  4. Mark (The Other Mark) says:

    "At any rate, when 64-bit Windows was introduced, the plan was not to do things the crazy mishmash way and instead separate the 32-bit files into one directory and the 64-bit files into a different directory."

    A decision with which everyone agrees with, and no one ever mocks, particularly not folks who don't understand that 64 Bit Windows predates WoW64.

  5. foo says:

    > and your batch file that ran rundll32.exe with some goofy command line still worked,

    WOOO!! And that is the only instance of that :)

  6. I need a time machine says:

    If Apple designed Windows we'd have universal binaries instead of this mess.

    [The downside of universal binaries is that they take up a lot of disk space for architectures you may not need. At the time this decision was made, your typical hard drive was around 30MB (with an M), so conserving disk space was important. Apple had the luxury of waiting until 2005, when typical hard drives were 250GB. -Raymond]
  7. Maurits says:

    I suppose we could bring back rundll.exe now as a hotlink to rundll32.exe.

  8. Anon says:

    Apple: Waits a decade after everyone else to implement something, hailed as the first to do it.

  9. David Heffernan says:

    Mildly funny that the person calling everyone else stupid couldn't even get the name right and called it runndll32!

  10. ZLB says:

    "If Apple designed Windows we'd have universal binaries instead of this mess."

    If it was Apple they would happily just break old programs/batch files etc. They have a different outlook to backwards compatibility.

  11. smf says:

    What is the history of rundll in NT? As dual 16/32 predated Windows 95 by a couple of years.

    [Rundll/Rundll32 was introduced in Windows 95. -Raymond]
  12. Chris Dahlberg says:

    Expanding Karellen's comment into a question, is there an explanation for why the System folder with 32 in its name (System32) contains the 64-bit binaries and the System folder with 64 in its name (SysWOW64) contains the 32-bit binaries?

    [I'm sure I discussed it before. It's so that people who hard-code "system32" get the right version. -Raymond]
  13. foo says:

    > Apple: Waits a decade after everyone else to implement something, hailed as the first to do it.

    Wow. http://www.folklore.org. Everyone is awesome.

  14. Erik F says:

    Reading one of the early KB articles on rundll (support.microsoft.com/…/164787), I'm still not certain about its original use but I have a couple of theories. The first is that this method would allow you to "load" a DLL out-of-process in a standardized fashion (useful for OLE/COM?); the second is that you would be able to call a 16/32-bit DLL from a 32/16-bit process without thunking (or, I suppose, a 32/64-bit DLL from a 64/32-bit process).

    I like that the article states: "The Rundll and Rundll32 utility programs were originally designed only for internal use at Microsoft. But the functionality provided by them is sufficiently generic that they are now available for general use." Sounds like famous last words to me!

    [The original purpose was that the shell team didn't want to create 100 separate EXEs [see: 30MB hard drive], so they created one EXE (rundll.exe) that let you say "Hey, use that function in that DLL as if it were your main()". -Raymond]
  15. NB says:

    I remember double-clicking this file (among others!) when I explored the system directories in Windows 95 way back when. It didn't seem to do much though ;)

  16. Dominic says:

    Never attribute to luxury what can be explained by incompetence.

  17. xpclient says:

    Winhelp.exe's 32-bit binary had to be called Winhlp32.exe to fit the 8.3 name.

  18. dave says:

    Obviously, calling the new (new for 32-bit Windows) program 'rundll' was insufficiently forward-thinking.  It should have been called 'advrundll'.

  19. Cesar says:

    On a similar way, I learned that you should always use regedt32.exe instead of regedit.exe, because regedit.exe doesn't support things like permissions.

  20. Gabe says:

    Cesar: Regedit.exe and regedt32.exe were entirely different programs which just happened to have a similar purpose. Originally the registry was just for managing OLE configuration, so the regedit.exe was very simple. That registry only had keys — no values.

    Then Windows NT came along and expanded the registry to hold configuration for the whole system. They added more roots, security, and typed values, and remote access. Obviously a new editor was needed for editing the 32-bit registry, so I guess it made sense to put a 32 at the end of the name. Since WinNT had to install on down-level FAT systems (8.3-only), all filenames had to conform to 8.3 conventions.

    When Win95 came out, they updated the regedit.exe to support the additional roots and typed values, yielding the basic Regedit as you know today. Somewhat later they decided that having two similar registry editors was redundant, and added the missing features to Regedit so they could stop shipping Regedt32.

  21. Joshua says:

    [The downside of universal binaries is that they take up a lot of disk space for architectures you may not need. At the time this decision was made, your typical hard drive was around 30MB (with an M), so conserving disk space was important. Apple had the luxury of waiting until 2005, when typical hard drives were 250GB. -Raymond]

    And it wouldn't have worked. This program is the rare beast where the bitness of the program comes from the bitness of its first argument.

  22. Cheong says:

    [If it was Apple they would happily just break old programs/batch files etc. They have a different outlook to backwards compatibility.]

    Agreed. Before OSX, everytime you upgrade your Mac, none of your old prgram will work on the new system and you have to buy everything you need to use again.

  23. Nitpicker (Corner?) says:

    [The downside of universal binaries is that they take up a lot of disk space for architectures you may not need. At the time this decision was made, your typical hard drive was around 30MB (with an M), so conserving disk space was important. Apple had the luxury of waiting until 2005, when typical hard drives were 250GB. -Raymond]

    250GB hard disks in 1994 (the 68K -> PowerPC changeover)? Must have missed that…

    [Wikipedia says "The universal binary format was introduced at the 2005 Apple Worldwide Developers Conference." So Wikipedia lied to me. -Raymond]
  24. Eddie says:

    @Nitpicker (Corner?)

    I remember 1994, The average hard drive was less than 1GB.  If your Mac/PowerPC computer had a 250GB hard drive then congratulations (must be nice to be rich).

    As for us PC people there weren't any 250GB drives around in 1994 (not in any way that was price-friendly to the consumer).

  25. dbacher says:

    @Nitpicker (corner?):

    Raymond's point is that in 1994, Windows moved from 16bit to 32bit (technically before that — but I'll let that slide), and a 100mb hard drive was luxurious in that time period.

    The counter argument runs like this.

    In 2003, Microsoft was supporting at least 16-bit, 32-bit, Power, Alpha and Itanium.  That means 5 copies of the code, for the single binary approach.  One of which is relevant to the user.

    We were deploying on 3.5" disks still for many customers, at their request.  So instead of 20 disks — and yes, we were at that level (don't know about Microsoft) — you'd be talking 100 disks.  And we were all code, no data at all, on our install.

    That's a lot of added cost, it's a lot of disks to ship, it's a lot of disks for the user to juggle to install, and its a lot of space on their hard drive for bytes that their machine will never, ever load.

    I pay by the byte for data sent from Amazon, Microsoft or Google to users — the app store transfers are free, but are capped at 20mb over Cell networks in most cases.  And so every byte, it still counts.  a 1% reduction in executable size translates to hundreds of dollars for a modestly successful project.

    And then you have the fact that users are often running tablets with 8gb, 16gb of storage — and so shoving an x86, x64 and ARM version of the binary on that device makes no sense.

    And then, here's the kicker — if I install the x86 in one folder, and the x64 in another folder — how is that materially different from having one single binary?

    And does the user even care which one they run.  There's that issue to — when does an actual user care?  When they cross 4gb?  Not necessarily — lets say you're reading from the disk — if they've got 16, 32, more gb of RAM — that'll be disk cache, so who cares? :P  

    So you're talking an app that actively needs 4gb or more of data simultaneously before it even matters.  Since Windows just is running 32bit apps in 64bit memory space and zeroing the 32 most significant bits anyway.

  26. Ofek says:

    A similar puzzle pops to mind:  why the 64 suffix in all those DbgHelp functions and types?   (StackWalk64, EnumerateLoadedModules64 et.al.)   These were all alive long before Win64.

  27. Joshua says:

    [The original purpose was that the shell team didn't want to create 100 separate EXEs]

    Ah yes need to reduce the number of EXEs. The UNIX way was the multi-call binary but no way is that happening on Win95 (FAT16 filesystem!). I suppose they could have fixed FAT16 to allow hardlinks but then you couldn't dual-boot Pre-7 DOS on the same disk.

  28. Mike Dimmick says:

    @Nitpicker (Corner?): PowerPC Macs didn't have fat binaries, with all code compiled separately for both 68K and PowerPC embedded in the same executable. That choice could be made per-routine, with those routines written for 68K being executed under the emulator, and the PowerPC ones running native. Mac OS itself was mostly still 68K code on the first PowerMacs.

    Certainly developers had the option to make a fat binary by compiling all code for both architectures, but most started by just making the most performance-critical parts PowerPC code.

    In contrast, Intel Macs required fat binaries. Either the whole program must exist as x86 code, or the PowerPC code was executed with Rosetta. There was no partial emulation as for 68K code.

  29. Glaurung says:

    "Wikipedia says "The universal binary format was introduced at the 2005 Apple Worldwide Developers Conference." So Wikipedia lied to me. -Raymond"

    Universal binary =/= Application bundle.  The application bundle (all resources needed to launch an app exist in the app's directory, clicking on the directory's icon launches the app) was introduced on Macs with OS X, way back in 2001.  But it first showed up on NEXT workstations, a full decade prior, when hard disks were even smaller.

    [I was responding to the comment "If Apple designed Windows we'd have universal binaries instead of this mess." Universal binaries, according to Wikipedia, were introduced in 2005. Hard drive sizes in 2005 were different from 1989. -Raymond]
  30. ThomasX says:

    > (I will for the moment ignore the rude behavior of calling people stupid under the guise of asking a question.)

    The people were asked a question. Nobody called the people stupid. Therefore it is obviously obvious that the people feel stupid for their own reasons. Next time ask them what the reasons are.

    [FTA: "Please tell me this isn't yet one more stupid mistake of ms employees…" -Raymond]
  31. Cheong says:

    I think something like ARJ already has SFX+run support at that time, if there is just limited commands that need this special treatment, I'd think it's feasible (Whether it's worthwhile is another issue. My classmate bought his shiny Win95 PC with 1.5GB harddisk only, when the HDD I have in my home has 203 MB only.)

  32. Random832 says:

    [Universal binaries, according to Wikipedia, were introduced in 2005.]

    I think the problem is that people were using "universal binary" as a general term without knowing it's the name of a specific thing. Wikipedia asserts that "fat binary" is instead the general term, even though I associate "fat" with the specific implementation of the 68k/PPC changeover. "Universal" certainly _feels_ a lot more generic than "fat", especially knowing the latter was a novel use of the word coined by apple.

  33. Gabe says:

    Sven2: You don't understand why there needs to be both versions of an EXE. When the OS loads an EXE (before it even starts executing), the architecture has to be determined. Back then the OS needed to know if the process will be 16-bit or 32-bit. Nowadays the OS needs to know if the process will be 32-bit or 64-bit.

    If you had a 16-bit DLL to load, you'd have to tell Windows to load it with RUNDLL.EXE; if you had a 32-bit DLL to load, you'd start up RUNDLL32.EXE to load it. In order to be able to combine them into one file, MS would have had to both create a format that allows multiple bitnesses to coexist in a single executable (plus the build tools to create them) and a way for a batch file to tell which kind of process to create.

    Or with no additional effort they could just create two differently-named executables. Of course, nowadays they have the same name but are in different directories.

  34. Sven2 says:

    Why would universal binaries should take up more space. You could have binaries that contains multiple code segments for different supported architectures, but aren't required to ship every architecture in every binary.

    For rundll: There would be only one rundll.exe that contains both 32bit and 16bit code (and decides on context which one to use), but for paint, you would ship only the 32bit version.

    Effectively, you would just combine *.dll/*.exe and *32.dll/*32.dll into a single binary. I'd argue this would actually use less space than the current approach.

  35. 640k says:

    Now we will have to wait for 128-bit Windows before the exe file will be named correctly, without and bitness in the name. :(

    Only bitness in the name does NOT constitute an architecture.

    Universal binaries also includes non-x86, and non-86-64 architectures. The SysWOW64 does NOT have support for that, the day MS needs to support both x86 and ARM, they will have to invent yet another hack.

    @Dave Bacher:

    All people in general actually, please don't use the call it "disk cache" when you're referring to file cache. OS file cache doesn't cache disk sectors, it caches *files*. If an app reopens a *file* nothing is cached from previous accesses at all. That's why disk accesses are improved by using an additional cache on another level in the stack. Please understand this or I will have to explain it again.

Comments are closed.