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?
Why you want a 64 bit version? Avast is compatible with XP 64 bit and it use 64 bit drivers.
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).
So, the answer is: it won’t happen in any near future, as there’s no need for it.
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.
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.”
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.
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.
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.
I cannot resist to comment on the “Pros” a little 
So, I’d rather rephraze the “Pros” as
Also note that 64bit applications will probably use more memory than their 32bit equivalents, just because they were “extended” to 64bits.
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).
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).
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.
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?
Are you sure that the eicar.com file works into a 64bits environment? I’m not sure, I’m just trying to learn…
My computer is running XP Pro 64-bit.
When I use explorer it cannot find the eicar.com testfile.
When I use Total Commander 32 → using the same windows, no restarts ← the eicar.com file is found.
Can you send my a 64bit virustest if avast! is not detecting .com files as virus from 64-bit API calls?
I’d like to conferm that the 64-bit driver is installed…
But does eicar.com is detected in a XP Pro 64-bit system?
I’m not sure, eicar test was made to run into a 32-bit system and I’m not sure it is a way to test the 64-bit or you should wait for another test.
Other possibility is trying to see the properties of the running processes using ProcessExplorer from www.sysinternals.com
Right click ashserv.exe process. Choose Properties and then Strings. See (browse for) if the type of the string is win32 or win64.
DOS programs are scanned (on-execute) differently than Win32/Win64 programs - the DOS subsystem of Windows passes the file to avast! driver before executing them.
In Win 64, you cannot run COM files (there is no DOS subsystem present) - so the system doesn’t pass the file to avast!. As I said, however, there’s no need to worry, as the file couldn’t be started anyway (as the error message says).
The COM files are not scanned on-open (“on-read”) by default; if you add the COM extension to Standard Shield’s “Scan files on open” box, the file should be detected even in this case.
What is somehow suprising it that the file is detected when you run it from Total Commander… maybe TC starts it in a different way. I’ll check it, but I’d say you don’t have to worry - everything is OK.
Igor, won’t it be possible to run 16bits applications anymore?
Is Windows Vista a 64bits OS or, on contrary, it will allow DOS subsystem?
If I am not mistaken, Vista is not (necessarily) 64bit OS but it will not run 16bit programs anyway…