WINE and Bitage

Hey Alan (and everyone else :) )! You have two things going on here: different "bitages" and trying to get a Windows program to work in Linux. (I'm probably preaching to the choir, because you seem to know your stuff. But that's how it is..."My name is Bob, how may I help you? Is the computer plugged in? Is it on? Do you see a desktop?"...yeah - that stuff)
When trying to do something you did in Windows in Linux:
1. Are you convinced to ONLY use the program you were using before, and not even try a free program that does at least the same general thing that will work natively in Linux? Have you looked for a free Linux alternative that does that same thing and were unsatisfied with all others or found your original superior? Remember, if you find an open source one that looks good (maybe even your original was open source!), and there is no "Linux version" up for download, you can probably compile from source for Linux (had to do that for Handbrake)! Maybe the "alternative" will actually be better than the "original."
2. If you can't waiver, find a Linux version, or compile for Linux, then you're going to want to use WINE, and if that doesn't work, you'll have to resort to a virtual machine (unless you're ok with a dual boot, but you can't do that if the program is incompatible with your processor - then you'll have to use a processor-emulating virtual machine program, as opposed to a virtualization virtual machine program.).
3. If you're ok with trying a different program that does the same thing (Like LibreOffice - pretty darn similar to Microsoft Office.), look for a Linux alternative. Alternativeto.net may be a good resource. If you get no hits, try searching for "open source ______" instead of "Linux _____". If you have to (or even if you don't have to, and want to), compile from source.

The true wonder of a processor is that it can execute a program written in certain terms without having those terms defined elsewhere.
You COULD just run one program at a time directly on the processor. But that would mean that nothing could regulate it, and a malicious program could do bad things. Very bad things. Because nothing could deny it any access to any hardware, memory, or anything. And running multiple programs could be ... difficult...to say the least.

OR you could tell the processor to run ONE program, and then tell THAT program to run all your other programs. That program juggles all the other programs, divvies out memory (RAM) to each, and passes their code onto the processor to be executed (ran). Such a program is called a supervisory program, also known as a kernel.

Since the kernel is the only thing ran directly by the processor, and all other programs are ran by the kernel, meaning the kernel passes their code onto the processor, you have to realize who's running who. Those other programs are at the mercy of the kernel. The kernel can refuse to pass all or part of a program's code to the processor. It can even deny a program access to certain memory addresses. It can deny any program it is running anything. That's how rights get implemented.

Since programs are ran on the kernel instead of on the processor, the program can be written in a combination of terms: those that the processor can directly execute, as well as other terms that the kernel has defined back in terms the processor can directly run, and when the kernel runs the program, it translates when necessary, and gives instructions to the processor that it can execute by itself, without them being defined elsewhere...black magic.

As far as the bitages go….
Not all processors process the same size chunks. Some processors process more at a time (registers size they call it). WMI calls it "AddressWidth". Some very early (pre-Win95) processors handled 8-bit sized chunks. Those were 8 bit processors. Later there were 16 bit processors. Later than that were 32 bit processors. At least 6 years ago, we saw the first 64 bit processors. When a program is compiled from source (or when written directly in assembly….which is spooky and pure sorcery), it's made for a certain processor (and kernel…usually), and one of the things taken in as a factor is how big chunks are to be to be thrown at the processor. So if you have the source code, you should just be able to compile for whatever processor and operating system (kernel) combo you want it run in, and be good (unless the program relies specifically on a certain kernel or processor…like hardware emulation programs). If the program was written directly in the assembly (the instructions a processor takes directly…different processors have different assembly instruction sets) for a certain processor, the program will have to be completely re-written for the other processor you want it to work in (may want to invest in a programming language this time, a program written in a programming language can be translated from programming language terms into terms that can be executed by a kernel and a given processor)…but on the flip side, the thing's probably so darn efficient, you could run it in a processor emulator and make up for the cost of emulation. Decompiling into C may or may not help much in re-writing for a different processor.

So some programs are made for processors with one bitage, and other programs, a different bitage. You can't run a 64 bit program on a 32 bit processor because the 32 bit processor can't take in chunks that big. A 64-bit processor, however, is "wide enough" to fit in either a 32-bit chunk or a 64-bit chunk. As far as I know, a 64 bit processor could technically handle a 16 bit program, because the processor is "wide" enough to "fit" it, but the assembly language of the 64 bit processor is probably too different than that of the 16, so the 16 bit program won't run on the 64, not because it isn't wide enough, but because it speaks a different language. However, there is another important thing to remember…
Remember that programs you run aren't running directly running on the processor. They are running in the kernel, which passes stuff on to the processor. So not only does the processor have to support the bitage of the program, but the kernel (a.k.a supervisor or supervisory program) must support the bitage of the program. If you have a 64 bit processor, it can run both 32 bit and 64 bit programs, but since you are running programs through the kernel, if the kernel doesn't support 32 bit programs, and only 64 bit programs, you aren't going to be able to run 32 bit programs with that kernel. Win95 and Win98 were "special" because they could handle both 16 bit and 32 bit programs.

Fortunately, the Linux kernel supports both 32 bit and 64 bit programs, so you can do 32 bit programs on 64 bit processors in Linux, but the other way around will require a different processor, because the processor doesn't have a wide enough intake to fit a 64 bit program through, not because of an inadequacy in Linux (Linux doesn't have inadequacies ;) ). You could emulate a 64 bit processor! If you make a virtual machine that has its own emulated processor (as opposed to making a virtual machine that shares the real processor with your host operating system), you could emulate a 64 bit processor, install an OS in that virtual machine, and run 64 bit programs in that. "Only" thing is, you have to emulate a processor as well as all the stuff that makes up a computer that is visible to a kernel…which is going to relentlessly leech your resources (put a heavy load on CPU and RAM).

VirtualBox is a CPU "sharer [called virtualization]" and QEMU and DOSBox are examples of CPU emulators. You could emulate a 64 bit processor on your 32 bit machine with QEMU* or Bochs IA-32 Emulation Project *
*source: http://www.thefreecountry.com/emulators/pc.shtml

As far as running 32 bit programs on a 64 bit processor while in 64 bit linux: http://www.debian-administration.org/articles/534

Know that WINE is not an emulator, and thus does not emulate a processor. WINE has something that in many ways is similar to a kernel. As far as the Windows programs ran in WINE are concerned, WINE basically is their kernel. They do have to go through it. WINE manages their memory, and gives them hardware info, things that kernels do. WINE poses as a kernel. The top half of a kernel deals with the programs it is running, and the bottom half deals with the processor. WINE is kind of like the upper half of a kernel that is a program that can be executed by a real kernel. Though, rather than passing code onto the real kernel to merely pass onto the processor, WINE actually translates the program calls of the Windows programs it is running into program calls that the real kernel can handle. Also to be a kernel, it must be directly running on the processor with unrestricted rights, which WINE isn't. WINE is really a unique, genius and efficient animal. Since the kernel has to support the bitage of programs it is running (because it's running them), WINE has to support the bitage of the program you are running in it (WINE's heart is it's "half-kernel", this still applies). Normal WINE only supports 32 bit programs. There is an experimental WINE64 that does 64 bit programs. But the WINE "half-kernel" is executed by the host (real) kernel…so without WINE emulating a processor…running a 64 bit program in WINE makes the WINE "half-kernel" a 64 bit program, and a 64 bit program cannot be ran by a host kernel on a 32 bit processor. In other words, WINE64 can't run a 64 bit program on a 32 bit processor. WINE64 can't run a 64 bit program in 32 bit Linux even if 32 bit Linux s running on a 64 bit processor, either. Note that you can't run 64 bit Linux on a 32 bit processor (without emulation).
Emulation = Slow.
Note that you can still compile "WINE32" (normal WINE) for 64 bit Linux, and have your 64 bit Linux kernel, which is capable of running both 64 bit programs and 32 bit programs (not all kernels can support more than one bitage), run this 32 bit program, the WINE32 "half-kernel", which is further running 32 bit programs. So you can still run 32 bit Windows programs in normal WINE in 64 bit Linux.
So you could make a virtual machine (on your 32 bit machine) with an emulated 64 bit processor via QEMU or Bochs, install 64 bit Linux in the virtual machine, install the experimental WINE64 in that, and then you can put the 64-bit Windows program in that…sounds like a disaster, but in theory, it has a chance. Or you could do a 64 bit virtual machine running 64 bit Windows running your program.

Or, you could use a Linux native (not that developed): https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FARM%20CortexM3%20STM32%2FDFuSe%20applet%20on%20Linux&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E&currentviews=609

You sound like you know for sure that your processor is 32 bit, but for 6 years, I thought that MY OWN processor was 32 bit, but it's actually 64 bit. How was I so duped? Sandra Lite, WMIC, Speccy, CPU-ID, PC Wizard, and Linux's HardInfo all said "32 bit." Why? Because I was booted into a 32 bit operating system, which kicked the 64 bit processor into 32 bit compatibly mode where it reports itself as 32 bit. How did I find out? I, without thinking it through, wanted to test to see if the 64 bit Linux installer on my thumb drive was set up right (bootable), and it booted on what I thought was a 32 bit processor. I thought, "Wait, how is this possible?" Then Wikipedia said that a Pentium D is, in fact, a 64 bit processor (and I found out about the compatibility mode from somewhere)! So be sure you really do have a true 32 bit processor. If it's actually 64 bit and you didn't know, you could save a lot of pain - put on 64 bit Linux, and use WINE64, but that's still experimental. But at least it's better than emulating a 64-bit processor.
, or dual boot with Windows 64 bit and run in that.

Cheers,
SpawnHappyJake