Det ser ud til, at Mats og min antagelse var korrekte. MS har rekonstrueret 64 bit regsvr32, så den baseret på mål-dll-bitheden kan afføde en ny 32 bit regsvr32-proces fra %SYSWOW64% for at registrere DLL'en. For at bevise dette, startede jeg procexp, spionerede på pop op-vinduet for 32 bit DLL'en, og her var hvad der dukkede op.
Et par ting at bemærke
- Kommandolinjen for 32-bit regsvr32-kortene med det 32-bit DLL-navn, jeg forsøgte at registrere
- 32-bit-versionen af regsvr32 er en underordnet proces af 64-bit-versionen af regsvr32
- Billedtypen og stikolonnen
Dette burde forklare præcis, hvordan det sker:
(kilde:alax.info)
regsvr32
vil starte det er en anden bitness tvilling internt for at matche bitness af DLL. Sådan lykkes registreringen. Du skal være ligeglad med, om du starter 32-bit eller 64-bit version af regsvr32
fordi det vil tage sig af mismatch.
Scenariet, hvor du skal passe på, er, når du starter regsvr32
fra Visual Studio som debugging-vært. Du vil have korrekt bitness der, fordi underordnet proces med faktisk registrering vil køre uden for debugger, og du vil ikke være i stand til at gå igennem din kode.