NOD32 appears/seems to use IFS instead of mini-filters.. :(

Hey,

it seems/appears that NOD32 2.5 uses the old IFS (installable file system) instead of the new mini-filters (released on 2003) basis, for their on-access scanners (AMON, etc.)..

This is bad, because the new mini-filters model with the Windows File System Filter Manager Architecture (http://www.microsoft.com/security/articles/rsa/enhance.asp) is so much better, faster, more reliable and have rich performance!

I don't know whether that is right or wrong, but the system requierements on the eset homepage only says Windows 2000, Windows XP, etc., but for the Windows File System Manager with the "new" mini-filters model, you need at least Windows 2000 SP4 with UR1 (Update Rollup 1 package for SP4.., http://www.avira.com/pub/avira/fileserver/server/windows/documentation/txt/README.TXT) or Windows XP with SP2..!

Can someone at/from eset/nod32 developers explain the situation and why not the really better mini-filters are being used?!

IFS are legacy filters and slow..

Thx in advance!

best regards,

iNsuRRecTiON

 

1) How did you know NOD32 2.5 uses IFS?

2) If what you say is true, then Eset probably was not aware of it, or

3) Many of their customers still use Windows 2000 SP4 without Rollup 1 or Windows XP SP1 or below

4) As supporting unified architecture, it is not profitable to develop separately with such filters only for Windows 2000 SP4 + UR1 and above and a separate version for Windows 98/ME/2000 pre-SP4 UR1/XP SP1 or below

5) It can appear as a "feature" in NOD32 3.0 to "magically" increase the speed (anyway, NOD32 is really fast at the moment)

6) So many other things

 

Hey,

there only two possibilities, either NOD32 v2.5 uses IFS or mini-filters..!

But if they use mini-filters, why Eset don't write the correct minimal requierements for this down on their webpage?

Windows 2000 SP4 without Rollup 1 don't have Windows File System Filter Manager Architecture, which don't support mini-filters, so they can only use IFS..

But I wait for an official answer from someone at Eset.

best regards,

iNsuRRecTiON

 

well, AMON is really fast currently and anyway I think the new v. 3.0 will use a different technology.

Anyway , I'm not so aquinted with these IFS or mini-filters so I can't state too many on this subject, but anyway are you not satisfied with AMON's speed?

 

Of course, there is always the possibility that Eset might not want users of pre-SP2 Windows XP, pre-SP4+UR1 Windows 2000 and older operating systems to raise doubts about why NOD32 runs so much faster on Windows XP SP2 and Windows 2000 SP4+UR1 computers (due to the usage of mini-filters).

It can cause feelings of bias against older OS and all that. Eset probably wouldn't want these unnecessary support issues until they drop Windows 9x support completely. As a result, NOD32 may have used IFS in order to maintain the same speed across both Windows 9x/ME and Windows 2000/XP.

 

Hey,

the speed of the overall NOD32 AV suite is ok and good, but why I should be happy/contented, if the speed could be better/improved by the use of only mini-filters!

I think you're wrong here and that is not the case..

In my opinion, that would be really great and useful, if NOD32 where faster and have better performance on Windows 2000 SP4 + Rollup 1 and/or Windows XP SP2+, because these systems are more secure!

So if the user would know the fact that NOD32 is faster on these systems with mini-filters, then they migrate faster to these updated systems and we are all more secure..

Then these users have two benefits from Upgrading/Migrating:
1. More secure system
2. Faster, more responsive system, because NOD32 is faster on these systems and have an better overall performance..!


So I hope you get, what I mean, and why I ask, whether Eset use these mini-filters with NOD32 or not!

best regards,

iNsuRRecTiON

 

Maybe it is asking for too much trouble for NOD32 to detect the Service Pack level dynamically, and then adjust if it changes. For example, suppose somebody has WinXP SP1 and installs NOD32. NOD32 would use IFS. Now, if that person installs SP2, should NOD32 detect that, and then switch over to mini-filters automatically? It would be nice, but it may also be asking for possible bugs or compatability problems. Maybe Eset wants to play it safe and use IFS, which is known to work, though at the expense of a little speed.

Now, for Windows Vista, that may be another story....

(Any opinions expressed in this post are solely my ramblings. They have nothing at all to do what is going on with Eset developers, unless by pure coincidence. )

 

Hey,

great, I get it, you want say, maybe Eset and their developers are too lazy for this and too lazy to implement such feature..!

best regards,

iNsuRRecTiON

 

I have no idea what you're talking about, but I'm quite happy with NOD32 as it is.

 

Maybe...

Actually, "lazy" is probably too strong of a word for me. I have no idea what they are doing in their secret laboratories. For all I know, they could be working on a mini-filter implementation, but keeping it under wraps until version 3.0. Only Eset knows for sure....

 

Hello,

I have been reviewing this message thread and been trying to understand the problem. What I am having difficulty understanding, though, is what sort of baseline is being used as a comparison.

Without getting into an "apples versus oranges" debate, can you give a brief example of an anti-virus program which uses mini-filters and has been configured so its options perform like NOD32's (where applicable) and let me know the time it required to scan your test system versus NOD32?

Also, it would help to know how your copy of NOD32 has been configured for testing, e.g., are you using the Typical install settings from the installation program, Blackspear's settings or some variation of these.

Regards,

Aryeh Goretsky

 

Hey,

sorry, too bad, that you don't understand my position and point of view.

The scan speed of NOD32 is ok, currently.

I simple want to know and ask, why not simply implement and using mini-filters, if they could improve the performance of NOD32 even more, further and make NOD32 faster?!

I don't understand what is wrong or what could be wrong with mini-filters.
(What are the goods for using mini-filters, you can see at my first post on the MS link..)

Don't you want NOD32 to be the fastest and best performance you get out of it?! I really think so.

So it's quite understandable, why I ask this and why I want to know whether NOD32 use it and if not, why not and whether they are going to integrate them into NOD32 v3 or not..!

I simply want an statement about this from the Eset developers.

There is no problem or such.

But it is confusing, because of the system requirements..

best regards,

iNsuRRecTiON

 

Hello,

In independent tests, NOD32 usually ranks as the fastest or one of the fastest virus scanning programs during disk speed tests with its current
architecture.

While is may be a general statement that using mini-filters instead of IFS to interface with the operating system is faster, it is not always going to be correct in every case.

NOD32's speed is the result of a great deal of architectural design work (planning, prototyping, testing, etc.) as well as extensive real-world experience working with operating systems like Microsoft Windows to determine where performance issues occur and remediate them.

The idea that simply changing the way in which the software interfaces with the operating system will result in increased performance without taking into account the number of man-years which have gone into optimizing the current interfaces is a flawed one.

It is possible to create a program using all the latest and new technologies which is very slow. Conversely, it is also possible to create programs which run much more quickly using older technologies. One of the best examples of this is (or was) deleting files under MS-DOS. MS-DOS didn't have very granular methods of deleting files, so all sorts of little utility programs were available to handle operations like this with support for things like dates, regular expressions and so forth. The delete utilities which used the newer File Handles service interface were much, much slower (often by an order of magnitude) than those which used the older File Control Blocks service. While handles were a lot easier for developers to work with and easiser to understand, FCBs were faster (even though they didn't natively support directories and network structures).

To give a more contemporary example, I used to work at a chat/instant messaging company (Tribal Voice, who had a product called PowWow, both long gone now) which offered both 16-bit versions of our product for Windows 3.1 and a 32-bit for Windows 95 and NT 3.51. The 16-bit version of the product used less memory and was just as fast as the 32-bit version under Microsoft Windows 95 and NT 3.51. For such applications, though, the usual limiting speed was how fast the user could type. Anyways, users clambered for a 32-bit version (which we provided a few weeks after Windows 95 went gold) and even preferred it over the 16-bit version, even though the only different was that is used slightly more memory.

While it is true that new functions and APIs and services typically allow developers to make more immersive computing experiences with richer feature sets, it is not always true they are better or will even improve the performance of the application.

Regards,

Aryeh Goretsky

 

The new technology is not purposely designed for some product, when you make a chage, you should care about the other changes. For example, abacus computation has thousands years of history, but is much faster than computer when doing addition, abacus is make of wood, but is typically faster for the input and calculate. Input time make the computer much slower.So in our country every accountant have to learn abacus. It cann't not displacedd by computer. The new technology is not always superior in every aspect.

 

One post removed.

Any further posts with the same attitude and disrespect will be removed without notice.

Blackspear.

 

~snip....Gratuitous remark removed....Bubba~

Then, would you please care to explain, does the highly respectful above post by agoretsky contain information that

• micro filters are slower than IFS; or

• that they may be slower if not used properly; or

• it does not contain any information about that at all?

 

Hey,

yes I know, that's not the point, we all know that NOD32 is the fastest in scanning, but I don't ask, why you don't use mini-filters, because NOD32 is not fast, I ask it because it could even faster as it is currently, anyway..

True and sure, the same goes to 32 bit/64 bit, it's the "drawback"/kind of its nature.. Apps in 32 bit which runs fast and are great, but the same in 64 bit almost ever "consume" more memory as in 32 bit..

So maybe here the drawback of not using mini-filters, because your tests show that your "old" method behave faster and with better performance, is that NOD32 using more memory/RAM/resources as other AV apps. (E.g. KAV 6, even KIS 6, both use almost below 10 MB, NOD32 using always above 15 MB, often about 20 MB..)

I don't know whether that is true or not, but it could be..
(There are almost always some kind of "drawbacks"..or not?! )

best regards,

iNsuRRecTiON