As we know, the 64-bit system (like windows) can run both 32-bit applications or 64-bit applications. Under Windows 64-bit, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows 32-bit on Windows 64-bit, or WOW64 for short.
Here, I want to know, how can the 64-bit system knows the application is 32-bit or 64-bit? So, the windows 64-bit or WOW64 can be chose to run the application correctly.
By examining Machine field of the COFF header.
Related
Environment.SpecialFolder.ProgramFiles and Environment.SpecialFolder.ProgramFilesX86 returning x86
my pc is 64 bit
so how to get Program Files on Windows 64 in vb.net or #c
Dim ProgramFiles As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)
Dim ProgramFilesX86 As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
ProgramFilesX86 will always return the Program Files (x86) folder path while ProgramFiles will return the same path if your app is running in a 32-bit process and the Program Files folder path if your app is running in a 64-bit process.
If you target the x86 platform then your app will always run in a 32-bit process, meaning that it won't run on an OS that doesn't support 32-bit processes.
If you target the x64 platform then your app will always run in a 64-bit process, meaning that it won't run on an OS that doesn't support 64-bit processes.
If you target the AnyCPU platform and check the Prefer 32-bit box then your app will run in a 32-bit process if it can, otherwise it will run in a 64-bit process.
If you target the AnyCPU platform and uncheck the Prefer 32-bit box then your app will run in a 64-bit process if it can, otherwise it will run in a 32-bit process.
Your app would have been running in a 32-bit process because you checked the Prefer 32-bit box - note that it is checked by default - so your app could only see the Program Files (x86) folder, regardless of the OS. It doesn't make sense for 32-bit apps to do anything related to 64-bit processes.
I have installed crystal reports developer version along with runtime 64 bit. But when i run software my reports only work on developer edition not runtime-64 bit.. please solve my problem
When you develop an application that uses Crystal Reports you will need to install runtimes that match the target CPU of your application.
An application that targets 64-bit cpus specifically must have the 64 bit version of the runtimes. An application that targets 32-bit cpus specifically must have the 32-bit version of the runtimes installed. However, if your target cpu is set to "Any CPU", then you must install both the 32-bit and the 64-bit runtimes.
Targeting both platforms also leads to an issue that will actually prevent you from using the application on 32-bit systems. This is due to the application requiring the 64-bit runtimes because you can't install a 64-bit version of the runtimes on a 32-bit system.
Is it possible to load a 64-bit dll into a 32-bit process ?
Generally speaking, I know it can not happen.
Yet, maybe there are some exceptions ?
No, and neither a 64-bit process can load a 32-bit DLL.
If you're on a 64 bit OS, you can load the DLL in a 64-bit process and have it communicate with your 32-bit process through IPC.
If you're on a 32 bit OS, you're out of luck.
In .NET, it is possible to load a 64-bit DLL into a 32-bit process for reflection only. For details please check "Analyze 64-bit DLL from within T4 template in Visual Studio (32-bit) using Reflection".
I know that this is a special case, but I thought I'd add it anyway because it might help others looking for a similar solution as me.
Yes, you can load 64 code in 32 bit module. example:
vmprotect
metatrader4
above software mixed x86 and x64 in one process.
I found metatrade4 for win7 has a function it exeucte a instruction like :
jmp 0x33:0x175328
segment selector 33 is a 64bit segment. after execution this instruction, cpu will switch to 64bit mode from 32bit mode.
if you use windbg to trace some windows api on windows x64 OS, you will find similar code.
for example:
NtQueryInformationProcess
But new computer bought today at least have 4G ram. We cannot prevent using 64-bit OS to avoid problem. We must face 64-bit positively! Server 2008 R2 only have 64-bit.
Issues around EXE AnyCPU / x86, 32-bit COM / C++ dll must be handled.
Ideally compile both 32 and 64 bit COM / C++ dll.
We've got a DLL (a COM server) that will compile fine in 32-bit and 64-bit, but the DLL uses the same CLSID and AppID for the 32-bit version and the 64-bit version. Is this OK or does this have to change?
I'm asking this because apparently on a 64-bit machine, we can't register the 32-bit version and the 64-bit version together. It would be nice if 32-bit client applications could automatically use the 32-bit DLL, and 64-bit client applications could automatically use the 64-bit DLL.
On a related note, we have the source code and Visual Studio 2005 project file for a client application ... how do we compile a 32-bit and 64-bit version of the same application? It's a C# application, and it includes a reference to our COM server DLL like this:
<ItemGroup> <COMReference Include="ComServer">
<Guid>{C1FADEA6-68FD-4F43-9FC2-0BC451FA5D53}</Guid>
<VersionMajor>830</VersionMajor> <VersionMinor>0</VersionMinor>
<Lcid>0</Lcid> <WrapperTool>tlbimp</WrapperTool> <Isolated>False</Isolated>
</COMReference> </ItemGroup>
If it turns out that we need a separate CLSID for 64-bit, how do we make this reference "only for the 32-bit configuration" in Visual Studio? Or do we have to have separate projects with the same source code: one that refers to 32-bit DLL, and the other that refers to 64-bit DLL?
Both versions can (and indeed should) use the same GUIDs for everything.
On a 32-bit machine you can't register or use the 64-bit DLL, so there's no problem there. The 64-bit DLL simply doesn't enter the picture.
On a 64-bit machine the 64-bit DLL gets registered in HKLM/Software/Classes/CLSID (etc.) and the 32-bit DLL gets registered in HKLM/Software/Wow6432Node/Classes/CLSID. (I wonder where you got the advice that you can't register the 32-bit DLL on a 64-bit machine...) A 32-bit client running on the 64-bit machine will look in the normal place in the registry, but the OS will silently redirect it to the Wow6432Node key instead.
This is dealt with inside Windows with a feature called 'Registry redirection' On the 64-bit version of Windows, a 32-bit program gets a different view of the registry. Any access to the HKCR alias or the HKLM\Software root is redirected for the kind of keys that a COM server uses. A 32-bit program actually sees the key values stored in HKLM\Software\Wow6432Node. You can see it with Regedit.exe
This is normally taken care of by an installer, a VS Setup project has the TargetPlatform property for example. If you want to make the COM server available in both 32-bit and 64-bit mode then you should use two installers. Or a 64-bit installer that writes both sets of keys. Having a COM server that can handle both is very unusual in the olden days. But not unheard of when you implemented in .NET for example.
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.