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.
Related
i tried to create dir under system32 folder
but no exception shows or errors
note i run it as administrator
//1
if not TDirectory.Exists('C:\Windows\System32\oobe\info') then
TDirectory.CreateDirectory('C:\Windows\System32\oobe\info');
//2
if not DirectoryExists('C:\Windows\System32\oobe\info') then
CreateDir('C:\Windows\System32\oobe\info');
//3
try
ForceDirectories('C:\Windows\System32\oobe\info');
except
ShowMessage('cant create it');
end;
You have a 32 bit process on 64 bit Windows. Hence you are subject to the file system redirector. This redirects system32 to SysWOW64 which is the 32 system directory. You'll find your directory there.
You have these options:
Use the sysnative alias to access the 64 bit system directory.
Run the code in a 64 bit process.
Disable file system redirection.
The final option here is fraught with danger and is not to be recommended.
The documentation gives the details: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187.aspx
Of course, it's plausible that writing to the 32 bit system directory is exactly what you want to be doing and you have not yet realised that.
And finally, it would be remiss of me not to point out that the system belongs to the system and should not be modified by applications.
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.
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.
We have a windows service that uses dlls produced from a bunch of different .NET projects. One of those projects has a dependency on a dll that was compiled on 32 bit machine.
We have just moved the windows service to a 64 bit machine. By default .NET projects try to run as 64 bit assembly (because they are being run on a 64 bit machine). However, I can force individual projects to run as 32 bit assembly by specifying the Platform Target as 'x86' rather than 'Any CPU'.
My question is: do all the .NET projects need to be forced to run as a 32 bit assembly? Can 32 bit assembly and 64 bit assemblies be run together?
I think as long as you're not using native modules or anything, you're probably fine, though you can still have bugs in your code if you assume the size of a pointer, etc., anywhere.
"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."
http://www.hanselman.com/blog/CommentView.aspx?guid=4099df2d-ef01-4f70-a7f7-829eabc36afc
If there is no unsafe code and/or references on the unmanaged dlls you can safely compile everything with the target Any CPU.
The result of compilation is then CPU agnostic - the resulting IL is JIT - compiled by the CLR on the target machine, whatever the machine will be.
If the box is a 64 bit box it will be compiled to the by the 64 bit CLR to the 64 bit instruction set and will be happily run in the native 64 bit mode
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.