I'm not entirely sure that url (the hebbut.net one) has the very latest (and non-mainstream) CreateDLL code yet, but it should indeed work for Win 64-bit platforms anyway.
If not, drop me a line and I'll see what I can do, time allowing. (Which should be me updating that page...)
> > not delete the .dll. > > > > I must be missing something pretty obvious here?
One thing: CreateDLL is a tool which processes the generated .map file (produced by the first linker run) and generates the appropriate exports from that, feeding that to the second linker run (done from within CreateDLL). Without CreateDLL, you're stuck with a .dll which doesn't have the correct exports.
The alternative would be either reverting to static libraries only (OpenEXR generates multiple dll's) which is not a very nice way, or litter the code with declspec(dllexport) statements all over the place, which will prove to be a mess fast than you can say sh*te, especially in the presence of C++ templates. Been there, done that. Third option is also a major maintenance hassle: keeping your own handcrafted .DEF file around. Doable, if agonizing, for 'C'-based dll's, but when it comes to C++ exports, you'll get a headache pronto that way.
Ergo: CreateDLL is the fastest and easiest way to survive in Windows DLL County; just a couple of caveats to watch for; most important is to always remember to set up your MSVC projects to export a .MAP file at link time; this is NOT a default, so you have to make sure it's turned ON in your own MSVC projects when you wish to use CreateDLL for your own purposes (like I do).
Now I use CreateDLL (augmented version as available at hebbut.net) for all my dll-generating projects and that saves me a lot of hassle and pain.
So to cycle back to your question: keeping the initial build (= 1st linker run output) is a no-no as it would give you something that'll only /look/ like a usable dll but ain't.