When will there be a 64-bit version of Avast! ?

[Mr Snrub]

I have Windows XP Pro x64 Edition installed on my AMD64 system and went looking for a 64-bit AV product - I thought that Avast! 4.6 would be 64-bit.

ashDisp.exe
ashMaiSv.exe
ashServ.exe
ashWebSv.exe
aswUpdSv.exe

All of these processes are marked with a * in Task Manager, indicating they are 32-bit, not 64-bit.
Avast4 folder is created in "C:\Program Files (x86)" which further indicates this is a 32-bit product.

When will there be a native 64-bit version available?

[calcu007]

Why you want a 64 bit version? Avast is compatible with XP 64 bit and it use 64 bit drivers.

[RejZoR]

I belive NO antivirus works in pure 64bit mode. Remeber Win9x times? Well,although that was 32bit OS,90% of all software was 16bit or mixed with 32bit.
With Win2000 we have finally see pure 32bit mode. So don't expect any miraculs with WinXP 64bit edition noir programs for it.
WinXP 64bit can handle both 32 and 64bit applications,but drivers that operate at system level have to be 64bit (which indeed are in avast! case).
So i really don't see any need to rewrite entire program (very costly and time consuming task).

[igor]

So, the answer is: it won't happen in any near future, as there's no need for it.

[Mr Snrub]

Why would I want a 64-bit version?
Because like 16-bit apps running on W2K and later, 32-bit apps run in WOW mode which is a performance penalty.
System-level apps such as AV and firewalls should be as efficient as possible, IMO.

[igor]

The question is whether it really is a performance penalty, and if yes, how significant. I think the analogy with 16bit apps doesn't really match, the situation and underlying hardware is different.

Internet sources say something like "virtually zero emulation overhead", "no significant performance penalty", or "1-2% performance penalty compared to running those applications on a native 32-bit Windows OS."

[Mr Snrub]

Fair enough, but historically stability has also been an issue with emulation, and sometimes not all features are possible with backwards-compatibility.

If there are no plans for a 64-bit version then there aren't, but it seems like delaying the inevitable to me, and if projects like Far Cry and Quake 3 can be compiled for a native 64-bit version then I wouldn't have expected it to be that significant a task by comparison.

[RejZoR]

Remember,Far Cry is a game,avast! is an antivirus. Far Cry won't touch deep into system while avast! does regulary. It's a system app. You must understand that.
And why would they want to completely rewrite app into 64bit mode when it's working just fine in current (don't fix if ain't broken thingie...)? Drivers are indeed 64bit so there is no problem.

[Mr Snrub]

Regardless of whether an application is a system tool or a piece of software that requires 6 CDs to install, it cannot have been a trivial task to convert.
Ultramon 2.6 is a great example of a tool which has been modified to run as a pair of 64-bit processes, and SysInternals have had 64-bit versions of at least 3 of their system tools for a long time.
Another feature that is provided by 64-bit processes is the option for hardware DEP.

"If it ain't broke, don't fix it" is a great axiom for existing products, but this is in reality a new product as it would only execute on x64 systems - the code tree for the x86 version remains intact.

There is demand for 64-bit apps and tools from people who have migrated to a 64-bit system (maybe from some who did not need to, but perceived they would get a performance gain) and the first in each field to produce something that the users are asking for will most likely get a head start.
Avast! is a very professional looking product, in conjunction with Tiny Firewall 64 it can be seen to pretty much transparently intercept HTTP and POP3 traffic - as this is the only working solution for AV on XP x64 that I am aware of, there is a potential to push this advantage further.

I would love to see Avast! become a much bigger name in home AV solutions, and feel that we have buy-in for the product with suggestions that get implemented rather than dismissed.

If I can summarise what we have so far:

Cons...
i. work involved in compiling code to run as native 64-bit (would need doing eventually)
ii. no "need" for process rewrite ("if it ain't broke, don't fix it")

Pros...
i. performance increase through not using WOW32 (possibly not huge gain)
ii. stability increase through not using WOW32 (not measurable, but vital for system processes)
iii. access to all features of a native 64-bit environment
iv. hardware DEP would be possible (better security & stability)
v. demand for 64-bit would increase Avast! visibility, usage, popularity and generate more revenue (increased user base)

Also, given that MS are looking at producing their own AV, how likely is it that this will be 64-bit, and people will want to have alternatives of similar functionality?

I'll get off my soapbox now, this was just to demonstrate that there is a demand for 64-bit and it can come from reasoned-out arguments - at the end of the day I can only hope the decision is made to make Avast! 64-bit sooner rather than later, as it is an excellent product.

[igor]

I cannot resist to comment on the "Pros" a little

1. I believe there's really no performance gain for not using WOW64. The situation might be slightly different on IA64 platform (which nobody uses anyway), but the AMD64 platform is a "compatible extension" of IA32, so there's not much to "emulate" there, in my opinion.
2. I don't think there are any stability differences. Remember, we are not talking about 16bit subsystem (which would be somehow as comparing to Windows 3.x), but rather about 32bit subsystem (i.e. the "instable" part, you are talking about here, is a fully up-to-date WinXP, or rather Win2003).
3. Win32 processes have access to most of the OS features, and a few specials might be handled by helper 64bit modules.
4. I don't think DEP has anything to do with 32/64bit - it's a hardware feature, available even in 32bit Windows (if you are running the corresponding hardware).

So, I'd rather rephraze the "Pros" as
1. People will want 64bit programs, and it won't be possible to explain them that it doesn't really make any difference
2. There may be a slight speedup of recompiled 64bit applications caused by the fact that the 64bit CPUs have more general-purpose registers (so the compiler has better chance for optimization). However, it is easily possible that this slight improvement would actually be non-existent for applications like avast!. The main scanning code is quite "tight", so it's probably packed to x86 registers already, and a big part of the scanning time is taken by disk access, which wouldn't be improved either.

Also note that 64bit applications will probably use more memory than their 32bit equivalents, just because they were "extended" to 64bits.

[RejZoR]

DEP is supported on all 32bit processors in a bit limited form (in combination with Windows XP SP2).
Full DEP support was introduced with Athlon64 series. But this has nothing to do with 32/64bit. It's just that Athlons 64 fully support DEP,while other processors don't(just partially).

[Mr Snrub]

According to Process Explorer running on XP x64, native 64-bit processes get "Hardware" DEP status, with the default Windows settings 32-bit processes get "None".

If you launch a 32-bit app which spawns a 64-bit process, then the 32-bit app gets "None" for DEP, and the spawned 64-bit process gets "Software" for DEP.
(An example is cmd.exe launched by the Sourceforge app "Console" as an alternative command prompt.)

"Hardware" DEP is not limited to Windows processes alone, Ultramon 2.6, Process Explorer, File Monitor, Registry Monitor and the ATI Catalyst control panel processes all get "Hardware" for DEP status.

Change the default Windows DEP settings from:
 "Turn on DEP for essential Windows programs and services only"
to:
 "Turn on DEP for all programs and services except those I select"
and all 32-bit processes get "Software" for their DEP status.

Some of the apps/processes I tested were...
32-bit:
Avast! 4.6 (ashDisp, ashMaiSv, ashServ, ashWebSv, aswUpdSv)
Firefox 1.0.4
Tiny Firewall 64 (amon, rtshoo~1, UmxAgent, AmxCfg, AmxFwHlp, umxlu, UmxPol, UmxTray)
Thunderbird 1.0.2
Internet Explorer 32-bit

64-bit:
ATI Catalyst control panel (ati2evxx, atiptaxx)
Process Explorer
Ultramon 2.6 (UltraMon, UltraMonTaskbar)
Internet Explorer 64-bit
cmd.exe (plus all Windows processes)


So there does appear to me to be a functional difference in the degree of DEP support in 32-bit and 64-bit processes.

I believe the emulation of 32-bit apps on a 64-bit OS is at the OS level, not the hardware level - the CPU architecture has no bearing on it (it just allows 32-bit OS's to run natively as well as 64-bit OS's).

[rdmaloyjr]

I recently read an article about the new XP 64 bit operating system.  It was either PC World or PC Mag.    They said avast! was the only anti-virus with a 64 bit version.  They recommended using avast! to users of XP 64 bit until their choice of anti-virus came out with a 64 bit version.

Until???  This a good time for avast! to prove what a good anti-virus they are while it has a brief monopoly.

[bonfie]

Yo people,

My 64bit system is not detected by avast!

I downloaded the newest home version, and registered it.

When I run the eicar.com testfile from explorer, it just give a cannot execute error: not virus found.
When I run the eicar.com testfile from a 32bit app, it reports virus found!

So: How can I install the 64bit driver? I allready reinstalled 3 times, but the eicar is only detected if runned  from 32bit apps...

Is this because I am stupid or is my windows not correctly recognized?

[Lisandro]

When I run the eicar.com testfile from explorer, it just give a cannot execute error: not virus found.
When I run the eicar.com testfile from a 32bit app, it reports virus found!

Are you sure that the eicar.com file works into a 64bits environment? I'm not sure, I'm just trying to learn...