Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: Mr Snrub on May 27, 2005, 07:57:00 PM
-
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 ;)
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.
-
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?
-
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...
-
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.
-
In Win 64, you cannot run COM files (there is no DOS subsystem present)
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?
-
In Win 64, you cannot run COM files (there is no DOS subsystem present)
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...
-
Yes, it is not possible to run 16bit programs (DOS or Win3.1 apps) anymore in Win64. I guess Microsoft had enough to do to implement WOW (Windows 32 on Windows 64), so making it WOWOW would be probably too much. ;)
No idea about Vista, I'm afraid.
-
I all for a 64-bit version like it was before, in the same installer we had the 32 & 64-bit versions. I think is good for the foolowing reasons:
- 64-bit is the way to go because is the future of software, 64-bit versions of many programs are released.
- 32-bit software executes a little faster on a 64-bit CPU & OS that in 32-bit mode, but WOW64 kills the performance gain, so the effective performance is practically the same as the the 32-bit software on a 32-bit CPU & OS combo, so if 32-bit software run a little faster on a 64-bit CPU & OS combo, 64-bit software will run much faster for the following reasons:
+ 64-bit software processes twice the data at almost no cycles penalty per 64-bit machine instruction sent to the 64-bit CPU, AMD at
least has made this VERY clear.
+ You don't use WOW64 so you gain back the lost performance with 32-bit software, you get native, full-speed interface with the 64-bit OS
& drivers.
So Intel and specially AMD has focused on developing a mature 64-bit capability in hardware, so all the MoBos & devices manufactures so we can use a wider range of resources at fasters speeds, so why some software vendors deny this technology and advantages? too used to their comfort zone?
-
So Intel and specially AMD has focused on developing a mature 64-bit capability in hardware, so all the MoBos & devices manufactures so we can use a wider range of resources at fasters speeds, so why some software vendors deny this technology and advantages? too used to their comfort zone?
No.....they have a broad audience to serve, with limited resources. They have to balance what is most cost-effective for both them and the customer.
-
+ 64-bit software processes twice the data at almost no cycles penalty per 64-bit machine instruction sent to the 64-bit CPU, AMD at least has made this VERY clear.
Nope. Sure, the registers are twice as big, but most algorithms cannot take advantage of that anyway, so the size of the registers doesn't matter [if you're somewhere and want to get somewhere else by car, preferably as soon as possible - it doesn't matter if your car is twice as big now, it won't get you to your destination any faster; on contrary, you might actually be a bit slower with the bigger car, which is exactly the case here.]
And, if the particular algorithm is of the nature where wider registers help, there are already better technologies out there (SSE - with 128bit registers, available even in 32bit mode).
So Intel and specially AMD has focused on developing a mature 64-bit capability in hardware, so all the MoBos & devices manufactures so we can use a wider range of resources at fasters speeds, so why some software vendors deny this technology and advantages? too used to their comfort zone?
Because you only think that you'd get any speed benefit automatically - but the reality is often different.
Sure, 64bit is the way to go if you need to work with large data and take advantage of >4GB memory - image/video processing software, for example. But for most software, there's no significant benefit.
-
It doesn't, because it's a 16bit program (technically speaking).
-
I belive NO antivirus works in pure 64bit mode.
Sorry, but Microsoft Security Essentials and Hitman Pro both work in pure 64-bit mode.