Here's my scenario: the company I work has applications deployed to a 32bit Windows 2003 server and they want to move to a Windows 2008 Server that is 64 bit. It has been noted that these 32bit custom developed applications will not run on a 64 bit machine. I was not aware of this.
I have always thought that 32bit software CAN run on a 64 bit OS and just use the 32bit address. A 64 bit software on the other cannot run on a 32 bit OS. On a 64 bit, one does have to create 64 bit software but can and still also create software that is designed for 32 bit machines.
Can someone please elaborate on this?
In general, 32-bit applications will run under a 64-bit Windows (This is technically called WOW64 - Windows On Windows). This applies to all 64-bit Windows version to date, including Server.
WOW64 processes are marked in task manager with *32, For example: chrome.exe *32. Sysinternals' Process Explorer has a separate column for this: Image Type (64 vs 32-bit).
If the app has components hosted inside other processes, then those components must accommodate processes they're hosted in. Examples:
Shell extensions are hosted in explorer.exe, whose bitness matches the OS' bitness. Therefore, you should compile the extension in both 32- and 64-bit, and register the one matching the OS' bitness during installation.
Kernel-mode driver are hosted in the Kernel, whose bitness also matches the OS' bitness. So, the above applies.
Winsock LSPs (Layered Service Providers) are hosted in all processes, both 64-bit (native) and 32-bit (WOW64). Therefore, you should compile the LSP in both 32- and 64-bit, and register both in their respective catalogs during installation.
There are also considerations regarding file redirection (System32 / SysWOW64 / SysNative) and registry redirection (Wow6432Node), which I will not go into.
In general, 32-bit applications will run under a 64-bit OS. If your app relies on a 32-bit kernel driver (say, a VPN client), then you will have to port to 64-bit.
Related
I'm trying to debug a 32 bit program on 64 bit Windows 7.
So I use gflags to set the debugger for that app. I fill in the path of the application, and the one of the debugger. But when I start the application, WinDBG doesn't run.
The same configuration works on 32 bit Windows 7.
So, is it impossible to debug a 32 bit application on 64 bit environment?
For me this has always worked, even if I use the "wrong" architecture gflags.
However Windbg must be in the PATH, or you must include path when you specify the debugger to gflags.
UPDATE
This is an old question. Older versions of gflags used to store the settings in one of the locations:
HTML\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
or
HTML\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Depending on which architecture you pick for gflags.exe, it will affect either 64 bit or 32 bit processes.
Apparently at some point (thanks, #Thomas Weller to point it out), Microsoft changed gflags behavior and now (November 2016) current version of gflags.exe writes to both 32-bit and 64-bit registry locations, irrespective of the architecture.
This is a bit of a problem, because I used to use to attach 32-bit debugger to 32-bit processes and 64-bit debugger to 64 bit processes with the same process name. Now I cannot use gflags for this. However the workaround is to directly modify registry keys under Image File Execution Options.
Old Answer
Processor architecture of gflags.exe actually matters. If you use 64-bit version of Windows Debugging tools and launch gflags.exe from there, it will affect behavior of 64-bit applications. Similarly, if you use 32-bit version of Windows Debugging Tools and launch gflags.exe, it will affect 32-bit applications.
32-bit and 64-bit versions could be installed side-by-side. Pay close attention on bitness of application you are debugging and use the same architecture of the debugger/tools.
I wrote a 32-bit application that launches a 16-bit executable, which loads some 16-bit DLLs to perform some of the application's functions. It runs fine on Windows 7 32-bit, but not on Windows 7 64-bit since that version of the OS does not include the NTVDM.
The 16-bit portion of the code is pretty extensive and would be pretty expensive to port to 32-bit. Also, it uses some 3rd-party 16-bit APIs from a company that is no longer in business; therefore, that code would have to be recreated completely, thereby increasing the cost.
Is there any possible way to simply load the existing 16-bit DLLs directly from the 32-bit application, removing the 16-bit executable completely?
I've looked into thunking, but it doesn't appear that is supported in Windows 7 either.
You have to use an emulator or a virtual machine.
Or, if that is not an option then you can write a primitive emulator yourself, read the machinecode instruction-by-instruction and modify fake-registers and memory accordingly, and when the program calls outward then you will have to generate responses.
No. This is not possible in Windows.
I am going to make a device driver for 64 bit platform (i.e. Win7) and I would also like to expose device APIs in DLLs which could be distributed to users writing their applications.
The question is, how could I build such DLLs both for 32bit and 64bit applications?
The problem here is actually only about 32 bit one.
could I just write DLL and compile it in 32 as well as 64bit?
Or do I really need some IPC to wrap 64bit dll so that 32bit application can indirectly invoke device driver?
The translation between 32 and 64 bits should take place at the existing user-kernel layer. Your DLLs will use IOCTL commands to communicate with the driver, and the 32-bit DLL will have to use 64-bit IOCTL structures when the driver is 64-bit.
There's no need to add a second IPC layer.
Attempting to call SetupDiCallClassInstaller from a program compiled in 32 bit mode fails on 64 bit Windows.
Apparently this is by design, but I'd like to know the reason.
According to MSDN:
Device Installations on 64-Bit Systems:
The 32-bit version of the application must check the value returned by UpdateDriverForPlugAndPlayDevices. If the return value is ERROR_IN_WOW64, the 32-bit application is executing on a 64-bit platform and cannot update inbox drivers. Instead, it must call CreateProcess (described in the Windows SDK documentation) to start the 64-bit version of the application. The 64-bit version can then call UpdateDriverForPlugAndPlayDevices, specifying a FullInfPath parameter that identifies the location of the 64-bit versions of all files.
So it looks like any API that is designed to report ERROR_IN_WOW64 is specifically intended NOT to work in WOW64, a 32bit process has to invoke a 64bit process to call the API.
If you are making that call from a 32bit process on a 64bit OS, it fails because it has to modify some registry keys in the 64bit portion of the registry. Where else if you were to make that call from a 64bit process on a 64bit OS, it would succeed likewise with 32bit process on a 32bit OS.
Just a simple question: Is there any way to run a program compiled under a 64 bit Windows environment (with mingw64) on a 32 bit machine? Any DLL or any compatibility layer which I can use?
If you are talking about a 32-bit processor, then no. But if you are running a 32-bit OS on 64-bit hardware, then you can do it with VMWare. A 64-bit guest can run on a 32-bit host, if the hardware supports it.
Bochs should do the trick, but you'd need another copy of Windows to run in the virtual machine. (Some editions of Windows include additional licenses for virtual machines, so you might be in luck.)
Performance would probably be very poor.
No you cannot do this. The other direction is possible through an emulator, e.g. on Windows it is called WOW64.
It is standard practise on platforms that still have large install base of the 32-bit versions of the OS to ship either just a 32-bit version, or both 32- and 64-bit versions.
I can recommend VirtualBox for this purpose, you can download the free version and it's easier to use than VMWare. However you will need a 64bit installation CDROM, and storage space for a full system install, and if you are installing Microsoft Windows they will expect you to pay for a license key.
Also your CPU needs to support both 64 bit mode in the hardware, and the vt-X/AMD-V features (most of them do). It's a bit slower, although mostly that seems to be the display that slows it down, not the internal program calculations. This is NOT an emulation, the CPU is really running native 64 bit, but VirtualBox fakes the hardware devices (display, disk, network, etc) so the result is not as nice as running normally. 3D graphics acceleration is available, but it has limitations.
An easier option is simply to hire an online Virtual Machine by searching for someone offering 64 bit versions of Windows Server (there are plenty). Usually they will offer connection over Remote Desktop, typically you can pay by the month. Upload your programs, run what you want, then delete it when you are finished and cancel the service. The service provider handles installation, licensing, hardware, etc.
hey that was a problem that gave me a headache for a while but i solved it. I had windows 10 32 bit but when i opened system in control panel it said that "32 bit architecture, 64 bit processor." lookup some websites and your hardware must have a few things which you can check in CPU-Z( lookup some webpages for this) its necessary. Then export your folders,documents, softwares in an external hard drive..now download the windows 10 64 bit iso file and boot it.ands viola! you got 64 bit architecture ( i also recommend upgrading ram atleast minimum 4 gb) or the other way is to install 64 bit guest in VMware ir another virtual machine software...gud luck
No, It is not possible...........