[Spambayes] Windows 7

[Thomas Hruska]

skip at pobox.com wrote:
>     Ocean> You misunderstand.  If he's successfully running it with Windows
>     Ocean> 7 - 32 bit, you can't say that SpamBayes definitively works with
>     Ocean> Windows 7, because you don't know if it works on the 64 bit
>     Ocean> version.  You have to know it works fine on both before you can
>     Ocean> make a unilateral declaration like that.
> 
> I don't use Windows, however...

That's a shame.  It is a great OS that 90% of the world uses for their 
desktop OS.  :P

(Flamebait...)


> If he's installing a released version of SpamBayes (1.0.4 or 1.1.a4) he
> should be getting a Python interpreter as part of the installer.  To the
> best of my knowledge neither Mark, Tim, Tony nor anybody else who ever
> released a SpamBayes-on-Windows installer ever bundled a 64-bit version of
> the interpreter with it.  If a 32-bit interpreter will work on a 64-bit
> machine you're home free.  If not, then it would have bombed if he was
> running 64-bit Windows 7.  I conclude that either he was running on a 32-bit
> version of Win7 or a 32-bit version of the Python interpreter will work on a
> 64-bit version of Win7.  (Can someone with more knowledge of Windows than me
> -- that is, with *any* knowledge of Windows -- confirm or deny this
> conclusion?)  As far as I know there is nothing specific to 32- or 64-bit
> architectures in the SpamBayes source code itself.  All 32- or 64-bit
> dependencies would be in the binary code of the Python executable.
> 
> Skip

Hello.  I have in-depth knowledge about the differences between 32-bit 
and 64-bit Windows.

When it comes to drivers (for hardware), the driver has to match the OS. 
  32-bit drivers for 32-bit OSes, 64-bit drivers for 64-bit OSes.  No 
exceptions.

For software, Windows does a lot of funky stuff when doing 32-bit vs. 
64-bit.  For 64-bit programs, all DLLs and the EXE must be native 64-bit 
DLLs/EXEs.  In addition, Windows uses the 64-bit Windows Registry (but 
can be switched using some API calls).  The entire chain MUST be 64-bit. 
  The Windows loader will fail to load any 32-bit component.  The PE 
File Format (of which I am intimately familiar with) declares whether a 
component is 32-bit or 64-bit.

When the Windows loader encounters a 32-bit program under a 64-bit OS, 
it enters a sort of virtual machine environment known as WOW64 
(http://en.wikipedia.org/wiki/WoW64).  This is similar in nature to how 
we moved from 16-bit to 32-bit years ago (but less stupid).  The 32-bit 
Windows Registry is used and some file APIs are redirected (e.g. 
'C:\Program Files\' becomes 'C:\Program Files (x86)\').  Again, a 32-bit 
program aware of the 64-bit environment can call certain APIs and change 
this behavior.

However, there is perfect isolation between 32-bit and 64-bit.  A 64-bit 
program cannot load a 32-bit component into its environment and vice 
versa.  The Windows loader prevents it.  So, in-process, apartment 
threaded COM objects (such as the Outlook interface for Spambayes) have 
to match the application that is loading the object.  Here's an article 
on the topic of 32-bit vs 64-bit COM objects that is worth reading:

http://www.dnjonline.com/article.aspx?id=jun07_access3264

My personal experience is that, in most cases, Windows applications can 
simply be recompiled as 64-bit and it should work as a native 64-bit 
application.  The only issues that I've run across are:  Bad programming 
and assembler with optimized code for a 32-bit platform.

In the case of Spambayes, I don't see why recompiling for 64-bit would 
be much a problem.  It looks like Python currently has two separate 
versions:  One for AMD64 and one for IA-64 (instead of a unified build). 
  You aren't doing anything exotic (except for Outlook), so a 64-bit 
build is possible with potentially minimal effort.

-- 
Thomas Hruska
CubicleSoft President
Ph: 517-803-4197

*NEW* MyTaskFocus 1.1
Get on task.  Stay on task.

http://www.CubicleSoft.com/MyTaskFocus/