I've got a type library in a 32-bit Excel add-in app.
I need to translate the whole app to 64-bit.
I can't just copy paste the typelib, because the GUID's will clash with the already installed 32-bit app, ditto for the naming.
What's the best way to translate the application to 64 bit in a way that avoids name-clashes?
Or is there some mechanism that solves the name- and GUID-clashes automatically that I don't know about?
32 and 64 bit COM servers are registered in different registry views. So the 32 bit processes and 64 bit processes exist in disjoint GUID namespaces. In other words you use the same GUID for both 32 and 64 bit versions. The registry redirector does the rest.
Related
Just when I thought I understood Microsoft's confusing naming with regard to WIN32 and WIN64 registry and folders I read this article (Using 32-bit or 64-bit ActiveX Components on x64 Windows) and find myself still a bit confused on how to properly register 32 bit and 64 bit OCX controls on the same WIN64 computer. From the article it says that on a WIN64 system the default regsvr32 is for registering 64 bit OCX controls and to register 32 bit versions of the OCX control I should use C:\windows\syswow64\regsvr32.exe. The thing is I've been registering my WIN32 OCX control using the default regsvr32.exe (in C:\windows\system32) and it seems to have been working fine when I run my 32 bit app which uses the 32 bit OCX. I have the following questions:
Q1 How has registering WIN32 OCX with default regsvr32 been working given what I read in the article.
Q2 I want to register both the WIN32 and WIN64 versions of the OCX control on a single computer. From the article it seems like I should use the two different versions of regsvr32.exe from syswow64 and system32 for WIN32 and WIN64 versions respectively. Is this correct?
Q3 Can the GUID for the OCX be the same for both the WIN32 and WIN64 versions? I'm thinking it can be the same since a different portion of the registry is used to register for each of these architectures. Correct?
Q4 Where do I look in the registry to confirm that both 64 and 32 bit versions of the OCX have been registered to confirm that registering the 2nd one didn't overwrite the first one?
Per suggestion in comment by Andrew here is my comments as an answer.
A1 & A2 Well since no one has replied to this I'll add what I've learned since posting. It seems the article I referenced is misleading in describing how to run 32 and 64 bit regsvr32.exe. From my own testing it seems that the default 64 bit regsvr32.exe can be used to register both 32bit and 64bit OCX controls. It seems regsvr32 (the 64 bit version at least) looks at the target OCX or DLL file and determines if it is 32 or 64 bit and installs it in the appropriate registry. There doesn't seem to be any need to use the 32 bit version of regsvr32 on 64bit windows.
A3 Yes both 64 and 32 bit versions can be registered which use the same GUID.
A4 For 32bit OCX in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID area of the registry and for 64 bit its in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
I am writing a program in Delphi, and including a library which contains some assembly code (Pipes.pas). I am getting an access violation when I run the code which makes a call to a function called StdWndProc. The process is an assembly function which contains assembly code.
A while back I updated this code (Pipes.pas) to include unicode support and other stuff, but I didn't figure out what this assembly was doing. Any ideas on what's going wrong here?
I'm running on a 64-bit machine, could it be that this assembly is 32-bit and isn't running correctly on a 64-bit processor (the project is targeted at 32-bit build).
A 32 bit process executes 32 bit code. It doesn't matter whether that code was compiled from assembler or Delphi or some other language.
It doesn't matter whether the machine is 64 bit or 32 bit, a 32 bit process runs 32 bit code. On a 64 bit machine, a 32 bit process runs in an emulated 32 bit machine called WOW64.
Conceptually what you are attempting is possible, so the conclusion is that your code has a bug.
As David Heffernan pointed out the cause of your problem can hardly be the OS architecture.
If your code runs with no errors on 32 bit machines, but it fails to run on 64 bit ones, it could be an OS issue however. It could be caused because of the use of 32 bit-exclusive directories (like SD:\Program Files which is called SD:\Program Files(x86) on 64 bit windows for 32 bit programs), registry reflection (which causes your program to store registry data under the Wow3264Node key), or even the use of old 16 bit DLL s (that can not run under wow3264), but that is a very rare case since it is 2013...
To be able to help I need further details of how your code does not run correctly.
(Please note, that the original question is already answered, I only wanted to provide some more useful help.)
Considering the following:
We have a 32 bit Datasnap server installed on a 64 BIT Windows Server
In embarcadero\rad studio\11.00\redist are 2 folders : 32 bit and 64 bit, with in each a midas.dll.
Which file should we put where?
In windows\system32 or windows\syswow64?
On a 64 bit system:
The 64 bit system directory is named System32.
The 32 bit system directory is named SysWOW64.
If you must copy a DLL into the system directory, make sure that you copy 32 bit DLLs to the 32 bit system directory, and 64 bit DLLs to the 64 bit system directory. That's essential if you want your application to be able to locate the DLL.
Since your code is 32 bit, you need to use the 32 bit DLL.
However, you should probably place the DLL in the same folder as your executable since the Windows system directory is private and reserved for use by the system. Applications should not modify the system directory.
Never put anything in the Windows system directories (unless you have a very, very, very good reason to write there).
It's a very bad practice (dating back to Windows 3.x times and poor developers skills, because those dirs are always in the search path) just leading to troubles (i.e. if another application chnages your DLL with its own with little or no checks). Put the DLL in the application folder. It will ensure your application uses the correct version of the DLL. Or if you have to write it elsewhere for a very, very, very good reason use one of the techniques to add a directory to the search path or redirect DLL loading.
Windows system directories must be regarded as operating system private ones. This kind of practices which Windows doesn't forbids enough are those that often makes Windows a slow and unstable system.
If you're application is 32 bit, you need the 32 bit DLL regarless of the operating system.
My developer machine is a Windows 7 64bit and have some programs on 32 an others on 64 bits
since the upgrade of the 3.70FC3 and 3.70TC3, I'm having problems compiling with VisualStudio 2010 sp1.
maybe there is some configuration that I need to do to change 64 to 32 bit. Or maybe is not supported to have both csdk
If it is feasible, you select which is in use by setting $INFORMIXDIR (oops; I mean %INFORMIXDIR%) to the correct directory and any other related changes (the correct bin subdirectory added to %PATH%, etc).
If there isn't an easy way to switch such variables, then it may not be feasible; I avoid working on Windows so I can't report of my own experience. Classically, it was certainly expected that you would choose one version and stick with it. On Unix, it has been possible to have both, but there isn't the registry to complicate things.
I recently got a new laptop. Unfortunately, it came with Vista. It's been one big hassle getting it to work, and the comp has hardware components for which there are no XP drivers, so I can't "upgrade" to an OS that actually works. I've mostly gotten things working, but one particularly odd problem has me stumped.
I installed Delphi and tried to build a project. It compiled, but wouldn't run. "This application failed to start because sdl.dll was not found." Fair enough. So I grabbed SDL.dll and put it in the C:\windows\system32 folder. (Using Vista 64-bit Home Premium. This is a 32-bit dll, though, so I put it in the 32 folder instead of the 64 one.)
Hit Run again. Same problem. But why? That's where it goes, right? And C:\windows\system32 is in the system path. Anyone know why it can't link to the DLL?
(And yes, I know that I can work around the problem by putting the DLL in the same folder as the .exe. I'm currently doing that as a workaround. It's a bad idea in the long term, though, because I have a handful of different projects that all require SDL.)
That is not a Vista problem, but a 64 bit Windows problem: The name System32 is really confusing, but this is actually the folder where the systems (64 bit) DLLs reside.
So on any 64 bit version of Windows...
... all 64 bit system DLLs are located in C:\Windows\System32.
... all 32 bit system DLLs are located in C:\Windows\SysWOW64.
The name comes from Windows on Windows 64 (WOW64) which is the name of the translation layer allowing 32 bit applications to use the native 64 bit system resources.
Raymond Chen recently addressed the basic reason behind why 32-bit system directories are weird on 64-bit Windows. The first paragraph of the entry is really the key to understanding the reason behind segregated 32-bit directories:
On 64-bit Windows, 32-bit programs run
in an emulation layer...If a 32-bit
program tries to look at the system,
it will see a 32-bit system.
I think you'd have to have separate directories to keep these things all separate and working. The seemingly counter-intuitive name of SysWOW64 for the directory where the files reside is makes more sense when you consider that WOW64 means Windows On Windows 64-bit, which is what the emulater that's mentioned above is called.