NOD32 for Win x64-wrong...:-P

Hi there,

why Eset name the new 64 bit Edition of NOD, NOD32 for Windows x64 and not NOD64

I thought the "32" value in the NOD32 name stands for 32 bit and so, NOD for 64 bit have to be named NOD64, IMHO ;-)

best regards,

iNsuRRecTiON

 

Because then people would get it mixed up with the Nintendo 64?

 

It would be like McDonalds changing the name of its BigMac to littleMac if they brought out a bigger version. It's all about marketing.

Cheers

 

Probably because Windows XP Professional x64 Edition is not truly a 64-bit operating system.

 

Hey,

ooh, wow, one good and useful answer, the others are crap..

best regards,

iNsuRRecTiON

 

Actually, yes, it is. I'm curious -- what leads you to believe otherwise?

 

Not only is x64 not a true 64-bit OS, the AMD64 and EMT64 aren't true 64-bit processors. They only allow x86 to use 64-bit registers so that a system can have and use more than 4GB of RAM in a emulated 64-bit system (previously a technology called PAE was used to allow Windows to break the 4GB barrier but at quite a performance cost). A true 64-bit OS would need all new hardware which noone seems to want to buy so we are stuck with this workaround. Eventually an Itanium-like processor with IA64 will be able to emulate x86 fast enough to run legacy apps in a virtual machine that will make most happy and we will be able to move into true 64-bit computing. Until then, we get to live in a "64-bit" dream world hyped by AMD, Microsoft and Intel (the latter doing so reluctantly). Sadly, most everyone is falling for it, which means the transition from 30 year old x86 will continue much longer than it should.

Don't get me wrong, x64 and Server 2003 64-bit are great ideas for high-end workstations and servers needing more than 4GB of RAM (sure beats PAE in performance). But thats where it should stop.

 

Sorry, but this is one of those popular bits of FUD that's been floating around recently.

I'm a kernel driver developer and seminar leader in this field; I've spent much of my professional life in the last year and a half helping people port their drivers to these machines, debug them, etc. And anyone who's spent more than two minutes looking at the disassembly code in the debugger, let alone writing the odd bit of assembly code, will see that AMD64 and em64t do offer true 64-bit environments:

- Virtual addresses are extended to 64 bits. (This is far more important than RAM addresses, by the way. Damned annoying to deal with in the debugger too.)

- All general purpose integer registers are now 64 bits wide... NOT just for purposes of addressing memory, but also for integer arithmetic. All basic logical and arithmetic operations can now be done on 64-bit ints and unsigned ints. Just like on ia64.

- Speaking of general purpose registers, under x64's "long mode" there are twice as many of them. Again, this is not just widening the registers.

- Data paths to memory are at least 64 bits wide (as they have been on x86 environments for some time). This is really more a function of the memory controller than the CPU core, and if you ran the memory bus fast enough this really wouldn't matter... but there it is.

- Under Windows XP X64, all pointers returned by and passed to system calls (everything from the long mode version of malloc to MmGetSystemAddressForMdlSafe) are 64 bits, as are the size arguments for most allocations. And I can have processes that use more than 4 GB virtual address space. LOTS more. The current implementation limit is 8 TiB; when that becomes a limiting factor it'll be trivial to move the boundary.

This makes it a true 64-bit environment by any reasonable definition.

Yes, it supports 32-bit apps under the 64-bit OS, but that doesn't make it "not a true 64-bit environment". Is x86 not a "true 32 bit environment" because we can, if we want, address only 16-bit pieces of the GPRs and run DOS apps under NTVDM? Was the VAX not a "true 32 bit processor" because it included a 16-bit compatibility mode under which it could directly execute PDP-11 programs? Is it really a requirement to make up an entirely new instruction set, and abandon direct execution of legacy apps, before people will stop saying "not a true 64-bit CPU"?

It isn't truly a new instruction set, that's for sure! But, that's a different question.

By the way, I have no idea how Linux or anyone else will handle it... but under Windows, the 32-bit compatibility mode is strictly for user mode -- all kernel mode code (ring 0) is 64-bit. 64-bit pointers, 64-bit general purpose (integer arithmetic) registers, etc. This is why everyone has to port their drivers.

All new hardware? If you want. For example, it would be possible to put together an amd64 or em64t motherboard with only 64-bit PCI-X slots. But the CPUs qualify as "true 64-bit" already.

By the way, the width of the machine's registers (other than CR3) has NOTHING to do with RAM addresses. RAM addresses come out of page table entries, not registers.

And PAE is nowhere near as bad as many people believe. Forget anything you've read about PAE "paging things in and out of the lower 4GB" - that's just more FUD. It's just address translation as usual... but with three levels of page table lookup instead of the usual two under x86. The additional overhead is only incurred when you have a miss in the TLB, and it is usually more than made up for by extending RAM from say 4 to 8 GB, in environments that need it.

In fact, if 64 bits were only about increasing RAM size, there'd be NO reason for x64, as the way X64 supports large amounts of RAM is very much like PAE, just more so! PAE changes from x86's normal two-stage page table lookup to three stages; x64 uses four-stage lookup. And don't think Itanium will save you from that, because it does the same thing yet again, with a three-stage lookup just like x86 PAE!

I know this sounds expensive -- worst case, you have to do three memory fetches (four on x64) before you can do the memory reference you wanted to do in the first place -- but with these very large virtual address spaces, the alternative of very large virtually contiguous page tables would be even more costly. Both families make up for this by increasing the size of the TLB, which gets the address translation overhead back down into the range where it normally is on x86.

obtw, when you boot XP SP2 on a machine that supports /noexecute, you're running in PAE mode, even though XP won't let you use more than 4 GB RAM. It's necessary because there's just no place in a 32-bit page table entry for the no-execute bit. PAE makes room for that bit along with the additional bits of physical address.

 

Very good read and very informative, thanks.


Oh, we`re still not gonna call NOD32 NOD64 though.

 

I shall stick to calling the x64 version NOD32 DDR

 

Just, please, don't call it NOD32 XTREME EDITION!!!

/me remembers when every other software product was called "Turbo" something or other, and shudders

 

Hey,

yeah, a very thanks for this from me to you, jeh, too.

So what is about that Eset?

Any mod, admin, coder/programmer at Eset, please reply, thx.

best regards,

iNsuRRecTiON

btw. you can implement support for SMT/SMP for/in NOD64 e.g. for DualCore or Hyperthreading and improve it on that platform, too

 

Regardless of what it's called, the developers deserve kudos for getting an x64 version out and supported! If keeping the name the same helped that happen faster, that's a good thing.

 

NOD32 is coded in assembly, which is extremely fast and probably the fastest developer language. As far as I know, there is no way to optimize assembly code for specific CPUs.