What are some native 64 bit AVs out there?

Notice, I am asking for native and not "compatibility" support of 64 bit systems. So far I know the following AVs to be 64:
- Roboscan
- MSE
- Comodo
- Outpost SS
- Bitdefender

 

ESET has "real" 64-bit versions.

 

It could be that I'm the only one who doesn't get it but what do you mean by compatibility support? I didn't think it was possible to insert 32-bit AV drivers into a 64-bit kernel.

 

Any AV running on a 64bit platform has to have native 64bit drivers. The usermode component doesn't make a difference, provided the developers have correctly written the layer to handle passing of 64bit data from a 32bit application (which I presume they all will have by now considering the prevalence of 64bit platforms). Prevx had a dedicated native 64bit usermode application, but we opted to keep it 32bit for Webroot SecureAnywhere as it means you can have a single installer for both platforms and one binary to manage which just contains both a 32bit and 64bit driver and chooses which one to install. There are only inconsequential speed/resource differences between the two.

 

Outpost Security Suite has a separate 64 bit version. Or at least they did the last time I tried it.

 

Yes you are right. But it is possible to use 32 bit processes with 64 bit drivers. I am asking about AVs that use 64 bit processes and 64 bit drivers.

 

Bitdefender Antivirus and Internet Security are native 64-bit

 

AFAIK the only noticeable difference is that the memory usage is higher for a non-native 64-bit application; however people with 64-bit computers generally have more RAM than the norm anyway, so this is of no significance.

 

I think you are wrong - on contrary, the memory usage will be higher for native 64 bit applications (because many values will be stored in native, i.e. 64bit size, while 32bit would do just fine; also 64bit executable modules are generally bigger, if compiled from the same source code).

 

There is more differences than that... however in this topic I would just like to have a list of AVs that are native to 64 (processes + drivers)

 

You should probably remove ESET, as unless something has changed there are some 32 bit processes involved.

 

thank you

 

It shows Webroot in my 64b folder?

 

are processes 64 bit or 32 bit?

 

My bad, it's *32 in processes..

 

OP's question makes sense, because e.g. Windows Server 2008 R2 supports only 64-bit applications. Hybrid AVs (with 32-bit UI) can't be executed on this OS.

 

Doesn't Norton AV have a 64 bit only version? I think so....

 

thank you.

 

No, not at all. They don't even support 64 bit IE or 64 bit Outlook, something most vendors have supported for years. They do the bare minimum to support 64 bit Windows. They will be the last vendor for full 64 but support, kicking and screaming all of the way. I use them anyway, mostly due to the lack of problems it causes.

 

Then how come that x86/x64 combo products run fine on Windows Server 2008 R2 / 2012 ?

 

http://blogs.citrix.com/2011/10/13/wow64-memory-mapping-of-32bit-apps-running-on-a-64bit-windows/

 

Yes, but don't forget that to see significant effects you need to work with application with RAM usage in the order of GIGA and not MB or kb as in case of AVs application. As we all know by now the end results or advantages are negligle or basically null. Of course the original request by OP is very legimitate. I also hate to see *32 in my task manager!

 

The quote is incomplete though (from the original article). It further says:

The effect you mention - converting structures for system calls - is temporary (the stuff is converted, the call is made, and a microsecond later the memory is freed again), and IMHO negligible in size as well. The effect I have on mind is permanent - a 64bit application holds the stuff in "bigger form" all the time.

As jo3blac1 said, there are other effects (more registers, different addressing mode, possibly additional CPU instructions that can be implicitly assumed in 64bit mode) - but again, the effects are not always in favor, simply because the code is different. For example, when I compile the unpacking engine of avast! antivirus as 32bit and 64bit modules and do some benchmarking, I find out that:
- most of the unpackers are a bit faster in 64bit version (a few percent, nothing very significant), but some of them are also slower (by a similar ratio)
- the memory usage is usually very similar; in some cases, it's slightly smaller for 64bit unpackers (may be because of the WOW subsystem loaded in memory), but significantly bigger (e.g. by 50%) in other cases (those that heavily use pointers in their structures I guess)
- the executable file is about 30% bigger in 64bit.

Of course, all that depends on the particular file being processed, source code, compiler, hardware configuration, Windows version etc., so I'm not saying that's how it always is. I'm just trying to show that you shouldn't expect that "more bits is always better".


Anyway, sorry for the off-topic.

 

Of course

I opted to keep my box 32-bit, since I don't really see any applications utilizing more than the 4GB address space yet. If, and when that happens, I'll be sure to jump on the 64-bit bandwagon, but for now I'm doing just fine