F-Prot

[Zvi Netiv]

Actually it doesn't - a boot to DOS is no longer an "XP platform"

A platform isn't defined by what you boot to. Most users will call a platform
after the installed OS(s).

whereas a DOS window within XP would still be. Booting to DOS would not
support NTFS without the driver supplied by NTFS4DOS (for scanning) and
then you would need to pro version to affect any changes (write
capability).

Wrong again. NTFS4DOS is a free full access NTFS driver for DOS, from Datapool.
You are confusing it with NTFSDOS from Winternals. It's the latter that has a
pro version, required for full access (read-write).

Regards, Zvi

 

[Jafo]

...

Im sorry to disagree with you, but this is not true. I have
used FPROT for DOS on many XP machines and never had a problem.
You may have a problem on your machine.

Depends on whether the disk is FAT32 or NTFS.

 

[James Egan]

Depends on whether the disk is FAT32 or NTFS.

That's not it, either.

F-Prot DOS won't work properly in a xp dos window irrespective of
filesystem.


Jim.

 

[Yrael]

Why has this thread gone on for so long? I will try to finish it here.

It is perfectly simple. F-Prot for DOS will NOT run PROPERLY under a
Windows XP "platform", whatever your file system is. It will NOT run
PROPERLY using a NTFS file system. and it will NOT run PROPERLY under a
FAT32 file system either.

This is because Windows XP does not use DOS, it uses DOS "emulation". And
certain aspects of this DOS "emulation" are not compatible with some
advanced aspects of the F-Prot for DOS Antivirus Program.

Now, if you are going to boot your PC from a floppy disk or CD-ROM, then you
may be able to get F-Prot for DOS to work properly. There are lots of
options if you boot from a floppy disk or CD-ROM. You can choose DOS, DOS
with long filemame support, NTFSDOS Pro with long filename support etc etc.

But if you do this, then you are not running F-Prot for DOS under a Windows
XP "platform". You are running it under whichever "platform" you chose to
boot your PC with.

Simple isn't it?

 

[kurt wismer]

Zvi Netiv wrote:
[snip]

Wrong again. NTFS4DOS is a free full access NTFS driver for DOS, from Datapool.
You are confusing it with NTFSDOS from Winternals. It's the latter that has a
pro version, required for full access (read-write).

and of course *i'm* very interested in being able to access an ntfs
partition from dos (and maybe i'm not the only one)... thanks for the
heads up on that, zvi, i thought people were talking about the
sysinternals one - i didn't know about the one at
http://www.datapol.de/dpe/freeware/

now i'll just have to find some time to experiment with it...

 

[kurt wismer]

Yrael wrote:
[snip]

Now, if you are going to boot your PC from a floppy disk or CD-ROM, then you
may be able to get F-Prot for DOS to work properly. There are lots of
options if you boot from a floppy disk or CD-ROM. You can choose DOS, DOS
with long filemame support, NTFSDOS Pro with long filename support etc etc.

But if you do this, then you are not running F-Prot for DOS under a Windows
XP "platform". You are running it under whichever "platform" you chose to
boot your PC with.

Simple isn't it?

in order to not run afoul of zvi's point on what constitutes an xp
platform, you might want to revise this to state that you're not running
in a windows xp *environment*...

the _platform_ is kind of a red herring...

 

[Yrael]

Yrael wrote:
[snip]

Now, if you are going to boot your PC from a floppy disk or CD-ROM, then
you may be able to get F-Prot for DOS to work properly. There are lots
of options if you boot from a floppy disk or CD-ROM. You can choose DOS,
DOS with long filemame support, NTFSDOS Pro with long filename support
etc etc.

But if you do this, then you are not running F-Prot for DOS under a
Windows XP "platform". You are running it under whichever "platform" you
chose to boot your PC with.

Simple isn't it?

in order to not run afoul of zvi's point on what constitutes an xp
platform, you might want to revise this to state that you're not running
in a windows xp *environment*...

the _platform_ is kind of a red herring...

--------------------------------------------------------------------

Fair comment Kurt. I am not absolutely sure of the exact semantic
difference between a "platform" and an "environment" myself, or even if
there is one!

But I think the "original" query has been answered.

 

[Frederic Bonroy]

Yrael a écrit :

Fair comment Kurt. I am not absolutely sure of the exact semantic
difference between a "platform" and an "environment" myself, or even if
there is one!

Perhaps one could argue that the environment consists of the
hard-/software that is currently active while the platform includes
everything that is... well... "there", no matter whether it's being used
or not. The platform is perhaps more fundamental.

I doubt if there is a general agreement on what distinguishes a platform
from an environment if there is a difference at all.

 

[Zvi Netiv]

I don't think many would agree with that.

Really? Look then at http://www.answers.com/topic/platform

Cheers

 

[Art]

You are wrong. There was a time when I thought as you do. It looks
like it completes fully. However, you need to look very closely at how
many files are being scanned compared to how many you have.

How do you know for sure how many you have? Here's a interesting
tidbit from item 18 "Problems and Bugs" in the latest VTC reports
here:

http://agn-www.informatik.uni-hamburg.de/vtc/naveng.htm
---------------------------------------------------------------------------------
1.1 Problems very likely related to FindFirst/FindNext anomaly:
---------------------------------------------------------------
In several cases, scanners finished a first scan although they
had not touched all directories with infected objects. In such
a case, a postscan was started adressing only those untouched
objects; a second postscan was started when again objects were
observed untouched, but after the 2nd postscan, no more scan
was started. This behaviour may originate from a reported anomaly
in the behaviour of FindFirst/FindNext (those routines are used
to handle objects in directory trees) which has not been cured
so far by Microsoft.
-----------------------------------------------------------------------------

This was a Win 32 test, and platforms included Win 2K and XP.
Presumably, if a scanner happened to be using the MS LFN
FF/FN interrupt service, it would be subject to the alleged
bug. But so might a reference "bible".

To get back to DOS scanners, I read somewhere that it's twice as fast
to build your own FF/FN, as it were, based on low level BIOS calls.
Some DOS scanners might do this and have other bugs as well.
They'll never be fixed, since there's no marketing/business
interest in doing do. OTOH, some might work fine. There's the question
of what other DOS scanners are unsuitable/suitable for the NT based OS
with the FAT 32 option.

Art

http://home.epix.net/~artnpeg

 

[Roger Wilco]

Idiotic sophistry.

It depends on what you understand as an "XP platform". A PC with only XP
installed will be considered by most users as an XP platform, even when switched
off. Hence, not the running OS is what makes it a "platform", the installed
system does.

When my computer is turned off, it is only a platform for my monitor.

Okay, so F-Prot for DOS works fine on an XP platform as long as you are
not running XP.

Funny, that sounds even worse to me.

 

[* * Chas]

|
| >>Im sorry to disagree with you, but this is not true. I have
| >>used FPROT for DOS on many XP machines and never had a problem.
| >>You may have a problem on your machine.
| >
| >Depends on whether the disk is FAT32 or NTFS.
|
| That's not it, either.
|
| F-Prot DOS won't work properly in a xp dos window irrespective of
| filesystem.
|
|
| Jim.
|

The discussion has turned into a comparison similar to the 4 blind men
describing an elephant from 4 different locations - the trunk, the tail,
a leg and the belly!

Without an understanding of the situation, I have "run" F-Prot for DOS
in DOS Windows on NT4, Win2k and XP with both FAT32 and NTFS file
systems. I've also run it from a DOS boot floppy disk on the afore
mentioned OSs.

Whether F-Prot worked as intended is another issue. From all I've read
including Frisk Software, F-Prot for DOS didn't do a complete scan of
all the files is was configured to check on these systems even though it
completed the scans.

F-Prot for DOS is not completely compatible with the NTFS and XP file
systems - that's where the problem exists. It probably checks the boot
sectors and memory OK, after that????

Chas.

 

[Soundspider]

of course, if you identify a file in XP and tell FP dos to scan it and
it reports that it did scan it .. then it DID run.

The answer is that it doesnt scan the entire system without hand
holding and brainless button pushing.

However it does a dandy job of scanning your garden variety "is this a
problem" file

Oh and it also does a dandy job of scanning floppy disks that are IN
an XP system.


So in other words, it runs fine under XP. Just use it to scan files
and folders YOU pick, and it does what you ask.

Simple, isnt it ?

 

[Zvi Netiv]

[...]

Without an understanding of the situation, I have "run" F-Prot for DOS
in DOS Windows on NT4, Win2k and XP with both FAT32 and NTFS file
systems. I've also run it from a DOS boot floppy disk on the afore
mentioned OSs.
Irrelevant.

Whether F-Prot worked as intended is another issue. From all I've read
including Frisk Software, F-Prot for DOS didn't do a complete scan of
all the files is was configured to check on these systems even though it
completed the scans.

F-Prot for DOS is not completely compatible with the NTFS and XP file
systems -

That's not what Frisk say. FP for DOS is not compatible with XP. Period.
Besides, XP is not a "file system", it's an operating system, and the mention of
NTFS in this context is irrelevant.

that's where the problem exists. It probably checks the boot
sectors and memory OK, after that????

F-Prot for DOS doesn't check the boot sectors / MBR when run from the DOS shell
under XP (or under any NT derived OS) as direct disk access is not allowed by
the operating system.

Regards, Zvi

 

[Jafo]

I have "run" F-Prot for DOS in DOS Windows on NT4, Win2k and XP
with both FAT32 and NTFS file systems. I've also run it from a
DOS boot floppy disk on the afore mentioned OSs.

Really? Boot from that DOS diskette with a C drive that's NTFS.
Type dir c:
What do you get?

 

[* * Chas]

| As viewed from alt.comp.anti-virus, * * Chas wrote:
|
| >I have "run" F-Prot for DOS in DOS Windows on NT4, Win2k and XP
| >with both FAT32 and NTFS file systems. I've also run it from a
| >DOS boot floppy disk on the afore mentioned OSs.
|
| Really? Boot from that DOS diskette with a C drive that's NTFS.
| Type dir c:
| What do you get?
|
| --
| Jafo

A:\ C: Invalid Drive Specification Yep, been there.

I stopped using F-Prot boot disks when the definitions got too big to
fit on floppies and I can't find my old set. The only NT4 and Win2k
systems I currently have are multiboot PCs using FAT32 so I can't check
out what I did in the past. Maybe I was mistaken about booting to NTFS.

I just tried booting with a number of different DOS boot disks on one of
my WinXP NTFS laptops. No go.

Chas.

 

[Jafo]

"Jafo" wrote...

A:\ C: Invalid Drive Specification Yep, been there.

I stopped using F-Prot boot disks when the definitions got too big
to fit on floppies and I can't find my old set. The only NT4 and
Win2k systems I currently have are multiboot PCs using FAT32 so I
can't check out what I did in the past. Maybe I was mistaken about
booting to NTFS.

I just tried booting with a number of different DOS boot disks on
one of my WinXP NTFS laptops. No go.

Right. Next, download and install the ntfs4dos program (ntfsinst.exe)
from www.datapol.de/dpe/freeware/ . From the directory it creates on
your hard drive, copy the ntfs4dos.exe file onto that boot disk and
boot from the disk. Type ntfs4dos and hit Enter.

Now type "dir c:" (without the quotes)

You should be able to access your hard drive. No long filenames, but
you'll have read/write access.

 

[James Egan]

To get back to DOS scanners, I read somewhere that it's twice as fast
to build your own FF/FN, as it were, based on low level BIOS calls.
Some DOS scanners might do this and have other bugs as well.
They'll never be fixed, since there's no marketing/business
interest in doing do. OTOH, some might work fine. There's the question
of what other DOS scanners are unsuitable/suitable for the NT based OS
with the FAT 32 option.

That could be a useful utility to add to your list.

F-Prot DOS seemed to run okay on xp (fat32) when used within the
tech-protect front end (which created it's own scan list for f-prot).

I think they've given up with it though. Too many little quirks in
f-prot which frisk couldn't be bothered with fixing.


Jim.

 

[Ghostown]

Depends on whether the disk is FAT32 or NTFS.

Agreed. I typically dont use NTFS. If its skipping directory trees and
what not, I dont know what it might be missing, but its sure found things
many times before and gotten my butt out of a sling. )

 

[Roger Wilco]

Agreed. I typically dont use NTFS. If its skipping directory trees and
what not, I dont know what it might be missing, but its sure found things
many times before and gotten my butt out of a sling. )

The point of the discussion was to caution against trusting F-Prot for
DOS when it is running in the XP software "environment" even if FAT32 is
the file system in use instead of NTFS. It is NOT the file system (NTFS)
that makes F-Prot unreliable in that environment. Forget the side
discussion about what constitutes an "XP platform" because it is the
"environment" that the platform is currently running that matters - it
should not be XP's environment with a DOS session within.