I developed bootstrap software to start my game. I did this with Go. It was especially important for me to be cross-platform. Also, I didn't want to divide the download links into two as x86 / x64. I wanted to handle everything in one output. That's why I had to compile to x86. When I do this, I cannot properly detect that the operating system is x86 or x64.
In a software compiled as x86, how can i properly detect operating system x86 or x64 (in Go).
This code is not correct when compiled as x86.
const is64Bit = uint64(^uintptr(0)) == ^uint64(0)
On Windows you can call IsWow64Process to determine whether you are a 32-bit process running on a 64-bit OS. Note that it returns false if you are a 64-bit process running on a 64-bit OS, but if you have a 64-bit process running, then you know the OS is 64-bit or it wouldn't run.
Also note that 32-bit Windows is considered obsolete. Microsoft is already phasing out support for 32-bit Windows - they no longer want it to be installed on new computers.
On Linux you can call uname and look at the machine field. Here's a list of possible values. Note that most of them won't be compatible with your program, only i386, i686 and x86_64.
Related
Alright so my idea was some way to bind both 64-bit and 32-bit Windows executables into one application so if it doesn't run the 64-bit version it would then try the 32-bit one.
I was reading up about PE's and learned a little about MS-DOS Real Mode Stub and it says how it invokes an application (usually an error message). But every time I tried to do research about MS-DOS Real Mode Stub it seemed to only show error messages. So my idea was to overwrite the STUB with my 32-bit application.
My self being naive figured when the 32-bit operating system would run the the 64-bit executable it would fail and then run the stub file.
Is there any way to make my executable 32-bit/64-bit independent?
You could not create a single executable file, containing both x86 and x64 code. However you could create separate 32bit and 64bit applications, pack x64 app into the x86 app resources. On the program start you could check, that you are running x64 environment using IsWow64Process then if needed, unpack your x64 version and run it instead
There are fat binaries in MacOS, Linux and DOS (or hybrid DOS-Windows) but not 32 and 64-bit Windows
You can simply compile separate versions of the program, distribute both and then select the required version at run time by a script or another executable
Another way is installing only the desired version at install time. This is used by many programs like CCleaner. The installer is a 32-bit app or a universal one like .NET so that it can run anywhere. If it detects 64-bit Windows then it only installs the 64-bit version, and in the other case only the 32-bit version.
Read more:
Universal binary
Windows 8 fat binary (exe for x86 & ARM)
Windows NT has always been a multi-platform OS, but the binaries are not
I use windows 7 x64 with intel cpu. which windbg works fine and should I use for debugging x86 apps ?
and another similar question, I install windows XP x86 as vmware guest for kernel debugging.My host is x64 windows 7.which windbg should I use?, windbg x86 or x64 for kernel debugging ?
I don't want to say RTFM, but in this case that's where the answer is.
This is an extract from WinDbg help:
Host computer running a 32-bit version of Windows
If your host computer is running a 32-bit version of Windows, use the 32-bit debugging tools. (This situation applies to both x86-based and x64-based targets.)
x64-based host computer running a 64-bit version of Windows
If your host computer uses an x64-based processor and is running a 64-bit version of Windows, the following rules apply:
If you are analyzing a dump file, you can use either the 32-bit debugging tools or the 64-bit debugging tools. (It is not important whether the dump file is a user-mode dump file or a kernel-mode dump file, and it is not important whether the dump file was made on an x86-based or an x64-based platform.)
If you are performing live kernel-mode debugging, you can use either the 32-bit debugging tools or the x64 debugging tools. (This situation applies to both x86-based and x64-based targets.)
If you are debugging live user-mode code that is running on the same computer as the debugger, use the 64-bit tools for debugging 64-bit code and 32-bit code running on WOW64. To set the debugger for 32-bit or 64-bit mode, use the .effmach command.
If you are debugging live 32-bit user-mode code that is running on a separate target computer, use the 32-bit debugging tools.
It is usually best to match the debugger to the architecture of the application being debugged (sometimes even required). For debugging 32-bit applications, even on a 64-bit windows OS I would suggest the x86 version of WinDbg. I would use the x64 version of WinDbg only if I wanted to debug part of the WOW64 part of the 32-bit application, which shouldn't happen often.
i have a 64-bit machine with 64-bit OS...
how can i compile programs with Visual Studio 2010 so that they work on 32-bit system
if i install 32-bit OS on my 64-bit machine than i thinks it won't be a problem
If you are talking about .NET applications simply verify that you are targeting x86 in the properties of your project (this is the default setting) or Any CPU:
This is a nice property of just-in-time compiled code. It runs just as well on a 32-bit machine (using the x86 jitter) as a 64-bit machine (x64 jitter). The only time you get in trouble is when you need to use legacy unmanaged code that's only available as 32-bit machine code. Not uncommon with old dbase providers (like Jet) and COM servers. You've got the right kind of machine to detect these problems early.
Emphasizing: you don't have a problem if the target machine is 32-bit, only if it is a 64-bit machine.
I have seen that some programs which were written by me and assembled for x86 using ml.exe run fine on my Win 7 x64. I believe this is because of Wow technology.
However, there are some programs (not written by me) which don't run. They give the error that:
The version of this file is not compatible with the version of Windows you're running. Check you computer system infromation to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher
Is there any way I can modify the EXE of these programs to make it run on Win 7 x64. What is the fundamental difference in these programs which make it different from other programs which run transparently.
They're actually 8- or 16-bit programs. Windows x64 runs in Long Mode, which does not support Virtual 8086 Mode, required for such programs. There is no way to make them work short of recompiling them from source or running them in a virtual machine.
One reason can be combination of .NET and native libraries. .NET libraries are compiled in runtime as x64 (if you don't specify explicitly x86) and native libraries run in x86 mode. it cannot run togehther.
Another reason is access to registry. Depending on used API, x86app in wow64 mode can be forwarded to another part of registry. If the registry access API is inconsistent, it can make a problem.
Windows runs on x86 based CPUs only. Is it possible to make Windows run on non-x86 architecture CPUs like POWER, SPARC, ARM, etc.?
I know that there is a program viz., Virtual PC 7 for Mac that allows Windows to be run on PowerPC inside MacOS but not much detail is available. I'm talking about virtualization in a sense that allows HOST and GUEST machines CPU architectures be different.
Try QEMU: http://www.qemu.org/index.html.
Take a look at DOSBox (an x86 emulator) its an open source project that emulates x86 runs on a lot of platforms, and can even run Windows 3.11 on those platforms.
Windows runs on x86 based CPUs only
That's incorrect. Actually Windows ran on various different architectures such as IA-64 (Itanium), ARM (win CE, win RT, Windows phone...), DEC Alpha and even PowerPC, MIPS. Currently only x86 and ARM are supported. The last Windows for Itanium is Windows Server 2008 R2. See https://en.wikipedia.org/wiki/Microsoft_Windows#Platform_support
Many versions of Windows themselves can emulate other architectures. For instance Windows on Itanium has an emulation layer for running x86 applications on Itanium. The latest Windows on ARM also has a WOW64 layer to run 32-bit x86 code on 64-bit Windows on ARM. In the future it may subsequently gain the ability to execute 64-bit x86 code. Windows on PowerPC, Alpha and MIPS can emulate an x86 PC, too. See Did Windows NT 4 emulate x86 on non-Intel platforms?
But talking only about emulators then perhaps qemu and bochs are the most well-known ones
Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS. Bochs can be compiled to emulate many different x86 CPUs, from early 386 to the most recent x86-64 Intel and AMD processors which may even not reached the market yet.
Bochs is capable of running most Operating Systems inside the emulation including Linux, DOS or Microsoft Windows. Bochs was originally written by Kevin Lawton and is currently maintained by this project.
DosBox is also popular but it only supports real mode and protected mode, thus can only run Windows up to 3.x. It mainly focuses on running DOS-games, not Windows
Regarding the original title Instruction Set Virtualization, there are lots of emulators out there
If you're a gamer maybe you'll know some NES, gamecube, PlayStation 1, 2... emulators on Windows such as ePSXe...
Previous versions of MacOS X has Rosetta for emulating PowerPC on x86. When migrating from 68k to PowerPC they also used a Mac68k emulator to smooth the transition