File change detection utility for Win 9X/ME

[Zvi Netiv]

On Mon, 18 Oct 2004 11:22:36 +0200, Zvi Netiv

You again?

Yep, since you come back for more. ;-)

What's the point in running a av scanner in a AV scenario?

"An av ...", on both instances, mind you. And please don't change the subject.

[snip]

You're contradicting yourself again. If my program is worthless as you
say, why keep on coaxing me to improve it?

Is this what you think I am doing? ;-) What I am doing is assisting you in
hanging yourself from your own rope, and making a complete fool of yourself. I
must admit that you make me feel uneasy with your enthusiastic cooperation.

What error handling deficiency?

Program hanging when it can't write report files to its own directory, when run
of protected media.

As if I didn't know.

Whom are you trying to fool?

Solution without problems are worthless

Is your last statement meant to act as Mickey Mouse's sore smile on the last
scene of the Sorcerer Apprentice?

Bullshit. I've made no claims, nor have I misrepresented my program in
any way.

You did, amply.

Yet I'll give you another chance to save what left of your dignity, if you ever
had any. Prove me wrong by bringing here the name of just one reputed DOS
utility that does not run under plain DOS and would only run under Windows
9x/ME, and I'll rest my case.

Regards, Zvi

 

[Bart Bailey]

Solution without problems are worthless

Not necessarily so.
That was said when the laser was first invented,
but look at us now. <g>

 

[null]

Is this what you think I am doing? ;-) What I am doing is assisting you in
hanging yourself from your own rope, and making a complete fool of yourself. I
must admit that you make me feel uneasy with your enthusiastic cooperation.

Funny how you keep on describing yourself over and over again

Program hanging when it can't write report files to its own directory, when run
of protected media.

Back to that again. Very simple to fix. You make mountains out of mole
hills and make it sound as if some elaborate errror handling scheme is
required, which is just more of your BS.

Whom are you trying to fool?

Nobody. Fooling people is your province. I have no interest in going
there.

Yet I'll give you another chance to save what left of your dignity, if you ever
had any. Prove me wrong by bringing here the name of just one reputed DOS
utility that does not run under plain DOS and would only run under Windows
9x/ME, and I'll rest my case.

That's easy. Where have you been? My F-Pup download (F-Prot updater)
can't be run in DOS since it uses WGET to download files from the
internet. It's quite "reputable" from all indications I've had over
the years. Never hear any complaints about it and it seems it's used
by hundreds of thousands (perhaps millions) based on download counter
statisistics just at the claymania site (I don't use a counter
myself).

And I have a unattended mode F-Prot updater available as well which
can be run as a scheduled task in Windows.

Now, prove you can be a man of your word for once and rest your case.
Of course we all know that would be impossible for you.


Art
http://www.epix.net/~artnpeg

 

[Zvi Netiv]

On Mon, 18 Oct 2004 20:08:46 +0200, Zvi Netiv
[snip]

Program hanging when it can't write report files to its own directory, when run
of protected media.

Back to that again. Very simple to fix. You make mountains out of mole
hills and make it sound as if some elaborate errror handling scheme is
required,

If it's that simple to fix, then fix it instead of bullshitting around. You
know well that by the end you'll implement every single fix that I suggested.
I'll make you a concession when you do: There is need to give me credit in your
acknowledgments, for my contribution. ;-)

[snip]

I see that you are determined to commit harakiri. Then, so be it.

That's easy. Where have you been? My F-Pup download (F-Prot updater)
can't be run in DOS since it uses WGET to download files from the
internet. It's quite "reputable" from all indications I've had over
the years.

Since when is the self analysis of a mental patient acceptable as proof that he
is cured? You should be in a desperate position if this is all you could come
with.

Moreover, your F-Pup updater is irrelevant to the point as that program is only
required to function under Windows, uniquely, and therefore doesn't constitute a
DOS utility, and can't be considered as such. The implementation is immaterial,
just as are batch files (basically DOS entities) that contain commands to run
Windows applications or services.

And I have a unattended mode F-Prot updater available as well which
can be run as a scheduled task in Windows.

Doesn't count, for the same reasons as above.

Now, prove you can be a man of your word for once and rest your case.

What about the other way round, by fixing your program's flaws and deficiencies,
grudgingly if you must, and stop wriggling like a worm?

Lastly, may I draw your attention to the fact that not even a single poster came
to your rescue throughout the entire debate. Think what could be the reason?

Regards, Zvi

 

[Frederic Bonroy]

Are you kidding??? This is one of the BEST "useless
exchange(s)" we've had, here in a long time!

Yes! As if they were both running for president!

- "You are incompetent!"
- "Liar!"
- "You are too liberal with error handling!"
- "You jeopardize the security of the people of alt.comp.virus!"
- "You flip-flop on whether it's a DOS program."
- "[...] not even a single poster came to your rescue [...]". Maybe he
has alienated all his allies?



Sounds familiar? ;-)

 

[Zvi Netiv]

If it's that simple to fix, then fix it instead of bullshitting around. You
know well that by the end you'll implement every single fix that I suggested.
I'll make you a concession when you do: There is need to give me credit in your
acknowledgments, for my contribution. ;-)

Oops! Should read "there is NO need to give me credit ... etc.".

Zvi

 

[null]

Oops! Should read "there is NO need to give me credit ... etc.".

Credit? You really do deserve clown of the month!

Whatta idiot!


Art
http://www.epix.net/~artnpeg

 

[null]

On Tue, 19 Oct 2004 11:44:11 +0200, Zvi Netiv

More drivel. Like I said, you can't even once keep your word.


Art
http://www.epix.net/~artnpeg

 

[optikl]

Are you kidding??? This is one of the BEST "useless
exchange(s)" we've had, here in a long time!

Yes! As if they were both running for president!

- "You are incompetent!"
- "Liar!"
- "You are too liberal with error handling!"
- "You jeopardize the security of the people of alt.comp.virus!"
- "You flip-flop on whether it's a DOS program."
- "[...] not even a single poster came to your rescue [...]". Maybe he
has alienated all his allies?



Sounds familiar? ;-)

That's really very good. I didn't realize you had such a developed sense
of humor.

 

[Zvi Netiv]

On Tue, 19 Oct 2004 11:44:11 +0200, Zvi Netiv

More drivel. Like I said, you can't even once keep your word.

Is this your plead for mercy? ;-) Okay, granted! There is no fun in kicking a
dead horse anyway.

Zvi

 

[null]

On Tue, 19 Oct 2004 11:44:11 +0200, Zvi Netiv

I wasn't going to bother anwering this wriggling nonsense from Zvi but
it's so absurd I can't resist

Moreover, your F-Pup updater is irrelevant to the point as that program is only
required to function under Windows, uniquely, and therefore doesn't constitute a
DOS utility, and can't be considered as such.

It's precisely the same thing with F-comp. Both F-comp and my updaters
are 16 bit DOS programs which rely on being run in a Windows
environment (a DOS window) for their functionality. To say that one
program doesn't constitute a DOS utility while the other does makes no
sense whatsoever. In the case of the updaters, WGET.EXE is shelled by
the program making it dependent on Windows.. In the case of F-Comp, a
LFN interrupt service is invoked making it dependent on Windows. So
there is real difference at all.


Art
http://www.epix.net/~artnpeg

 

[Ant]

[snip]

In the case of F-Comp, a
LFN interrupt service is invoked making it dependent on Windows. So
there is real difference at all.

Just wondering... Win9x/ME runs on MSDOS 7 or 8, which you can boot
right into without starting Windows. Surely those versions of DOS
support LFNs?

 

[Zvi Netiv]

Just wondering... Win9x/ME runs on MSDOS 7 or 8, which you can boot
right into without starting Windows. Surely those versions of DOS
support LFNs?

The LFN support only starts with Windows loading, there is no LFN support
whatsoever under true DOS. The only provision for LFN that exists in DOS 7 and
8 is the protection of the long filename features of the file system from being
damaged by LFN unaware procedures. The LFN protection code in DOS 7/8 will halt
the system when attempting the use of LFN unaware applications, like old disk
maintenance and file system utilities (old SpeedDisk, NDD, Undelete, etc.).

Ironically, Art's F-Comp program doesn't use any of the LFN-exclusive services
that he claims depending on, from service 71A6 of Int 21 (like using the
filename long format for the service call, or with quotes, or the creation /
last access date). All that F-Comp uses (and needs) is the file attributes, its
plain time-date stamp, and the file size. The file name itself is represented
and processed in Art's program by its *short* DOS format (8.3), since the rest
of the program does not "understand" anything else. All the required info on
the file are provided by service 4E of DOS interrupt 21, which he uses
throughout the entire program!

The only "true" use that Art does of LFN, in the context of this thread, is
smoke and give the impression that there is need for, to save himself the
embarrassment of admitting the pathetic fool that he is.

Just to give the reader a complete picture, all file parameters that Art needs
and uses in his F-Comp program are available through INT 21h service 4Eh (DOS'
"findfirst - find matching file", effective under all DOS versions and in all
Windows' DOS box, since DOS 2 !!!). Ironically, Art uses Int 21 service 4E
anyway in his F-comp program, for listing files and directories.

Regards, Zvi

 

[null]

Ironically, Art's F-Comp program doesn't use any of the LFN-exclusive services
that he claims depending on, from service 71A6 of Int 21 (like using the
filename long format for the service call, or with quotes, or the creation /
last access date).

That's a lie.

All that F-Comp uses (and needs) is the file attributes, its
plain time-date stamp, and the file size.

Another lie.

The file name itself is represented
and processed in Art's program by its *short* DOS format (8.3), since the rest
of the program does not "understand" anything else.

That's true.

All the required info on
the file are provided by service 4E of DOS interrupt 21, which he uses
throughout the entire program!

That's a lie. .

The only "true" use that Art does of LFN, in the context of this thread, is
smoke and give the impression that there is need for, to save himself the
embarrassment of admitting the pathetic fool that he is.

Another lie. Two, in fact,

Just to give the reader a complete picture, all file parameters that Art needs
and uses in his F-Comp program are available through INT 21h service 4Eh (DOS'
"findfirst - find matching file", effective under all DOS versions and in all
Windows' DOS box, since DOS 2 !!!).

Same lie as above repeated.

Ironically, Art uses Int 21 service 4E
anyway in his F-comp program, for listing files and directories.

True, if the "ironically" clause is removed. A lie with it included.
So its actually another lie.

I count seven lies and one true statement. Pitiful


Art
http://www.epix.net/~artnpeg

 

[Gnome de Plume]

I count seven lies and one true statement. Pitiful

is Zvi running for US president by chance?

michael

 

[Bart Bailey]

I count seven lies and one true statement. Pitiful

Following Fred's implications, I'm surprised you haven't called
attention to that mysterious bulge under Zvi's jacket yet. <G>

 

[Zvi Netiv]

On Tue, 19 Oct 2004 11:44:11 +0200, Zvi Netiv

I wasn't going to bother anwering this wriggling nonsense from Zvi but
it's so absurd I can't resist

You should have resisted that urge, if you had any wisdom at all.

To further clarify the above point, then let me add this: Actually, your F-pup
program shouldn't be considered as a utility on its own. The utility in that
package is WGET.EXE, a Win 32 program for retrieving files by http and ftp, for
which F-pup is just the shell.

What governs the environment in which the F-pup package works is WGET.EXE, and
not your FP-up.exe shell program. FYI, the F-prot updater works fine under NT
based OS too (although you offer it solely for Win 9x/ME on your home page), not
because of your ingenuity, but because Wget.exe is properly written, which is
something I couldn't say about your stuff.

It's precisely the same thing with F-comp. Both F-comp and my updaters
are 16 bit DOS programs which rely on being run in a Windows
environment (a DOS window) for their functionality.

Rubbish. Your two packages aren't comparable. While F-pup is just an elaborate
shell to someone else's program, where the work environment is defined by its
main application - WGET, then F-Comp is a self contained program, where choices
for the work environment were all yours, and you blew it big time. If you knew
what you were doing, then there was no reason to choose a Windows 95 service,
when you could do the same with the good old DOS service 4E (findfirst) since
you use it anyway, and it provides the required parameters!

To say that one
program doesn't constitute a DOS utility while the other does makes no
sense whatsoever. In the case of the updaters, WGET.EXE is shelled by
the program making it dependent on Windows.. In the case of F-Comp, a
LFN interrupt service is invoked making it dependent on Windows. So
there is real difference at all.

I suppose you meant saying "so there is *no* real difference at all". I believe
I showed there is!.

As explained elsewhere in this thread, and above, your choice for the "LFN get
file handle" service was a gross mistake, and your waving with "reliance on LFN"
is a misrepresentation and eyewash.

Before we adjourn this round, then let me bring a few more comments on
additional flaws that I found in your F-Comp program:

When you run F-Comp for the first time, the program prompts for selecting one of
the drives, and creates a set of reference files for the selection. If there
are several drives on that PC, then there is no way to select more than one
drive for monitoring by F-Comp.

The only way to do that is to place a copy of the program in a separate
directory and initialize it for another drive. It's quite impractical to keep a
separate directory for every drive to be monitored, and run the program multiple
times, from multiple directories, on multiple drives.

Also, I couldn't find a way how to change the drive for monitoring, once the
reference files had been initialized. The only way to reinitialized the
reference of a specific instance of F-Comp for another drive, was to delete all
reference files in that directory and reinitialize it for a different drive.
Simply impractical.

As an engineer, seems that you never heard of quality control. All things
considered, I find your F-Comp program being worthless.

If you haven't any more silly remarks, then I'll rest my case.

Regards, Zvi

 

[null]

To further clarify the above point, then let me add this: Actually, your F-pup
program shouldn't be considered as a utility on its own.

Wrong. It has other capabilities besides the updater selection. BTW,
F-pup is just the name of the SFX download. The working program
"inside" the zip is named FP-UP.EXE

The utility in that
package is WGET.EXE, a Win 32 program for retrieving files by http and ftp, for
which F-pup is just the shell.

You have the tail wagging the dog.

BTW, there's a DOS version of WGET I used once long ago when helping a
guy out who wanted a purely DOS McAfee updater. He supplied me with
some dialup script and I put together a working program for him that
updates in plain DOS. I never did anything more with this even though
it has obvious advantages. For one thing, I'm a broadband junkie who
has no personal interest in dialup any more. And I'm not about to try
to tackle the problems of broadband in plain DOS or even try to find
out if it's feasible.

I did once hear from a guy (can't recall his name or handle) who used
to post here who claimed he was working on a F-Prot for DOS updater
that works in plain DOS. Dunno if he ever finished it or not.

What does work nicely is the use of your TOGGLMOD to run the FP-UP
program (or any F-Prot updater) in that type of Safe mode. So users do
have this "semi-formal" alternative to update when they're just
partially in deep doodoo and can at least get to this Safe mode. The
obvious problem is that this is not something average users will be
using or doing.

What governs the environment in which the F-pup package works is WGET.EXE, and
not your FP-up.exe shell program.

What governs it is my choice of the 32 bit version of WGET which only
works in Windows.

FYI, the F-prot updater works fine under NT
based OS too (although you offer it solely for Win 9x/ME on your home page), not
because of your ingenuity, but because Wget.exe is properly written, which is
something I couldn't say about your stuff.

That's because F-Prot for DOS is not specified for use on NT based OS.
My program is also a user interface for F-Prot for DOS. It also
creates a set of emergency boot disks only applicable for Win 9X/ME

Rubbish. Your two packages aren't comparable. While F-pup is just an elaborate
shell to someone else's program, where the work environment is defined by its
main application - WGET, then F-Comp is a self contained program, where choices
for the work environment were all yours, and you blew it big time. If you knew
what you were doing, then there was no reason to choose a Windows 95 service,
when you could do the same with the good old DOS service 4E (findfirst) since
you use it anyway, and it provides the required parameters!

Boy, you are the thickest and most stubborn SOB I've seen in ages
You can't get the info I want for my program from that very limited
and ancient DOS service. I want multiple file dates and I want to
present the LFN to the user. You seem completely locked into just one
of the modes of the F-comp program.

Before we adjourn this round, then let me bring a few more comments on
additional flaws that I found in your F-Comp program:

When you run F-Comp for the first time, the program prompts for selecting one of
the drives, and creates a set of reference files for the selection. If there
are several drives on that PC, then there is no way to select more than one
drive for monitoring by F-Comp.
Correct.

The only way to do that is to place a copy of the program in a separate
directory and initialize it for another drive.

That's what I suggest in my Info in the program.

It's quite impractical to keep a
separate directory for every drive to be monitored, and run the program multiple
times, from multiple directories, on multiple drives.

Impractical? No. A PITA? Probably. I doubt though that most average
users are interested in checking multiple drives and partitions.

If you haven't any more silly remarks, then I'll rest my case.

Well, I do feel compelled to point out your lies, distortions and
inaccuracies.

One other thing for those who may be interested. I noticed that Int
21h service 7143h can either get or set date and time on a file. And
all three sets of date-times can be set. Seems it might be easy for
malicious code to set a early set of dates on its files outside the
range searched by the top selection of F-comp.

I suspected this is the case. A date range search for newer files is
one of these "sometimes useful" heuristics in the case of malware.


Art
http://www.epix.net/~artnpeg

 

[Zvi Netiv]

Wrong. It has other capabilities besides the updater selection. BTW,
F-pup is just the name of the SFX download. The working program
"inside" the zip is named FP-UP.EXE

I am well aware of that and mentioned either executable, where appropriate.

You have the tail wagging the dog.

Not at all. The discussion is about fixing Fp-up , not Wget.

[...]

What does work nicely is the use of your TOGGLMOD to run the FP-UP
program (or any F-Prot updater) in that type of Safe mode. So users do
have this "semi-formal" alternative to update when they're just
partially in deep doodoo and can at least get to this Safe mode. The
obvious problem is that this is not something average users will be
using or doing.

Since you mentioned ToggleMode, then it's a fair example of a DOS utility that
runs in all environments, from pure DOS to the DOS box of *all* Windows
versions. Like your updater, ToggleMode acts as a shell for REGEDIT, among
other things that it does (edit System.ini, for example). Learn from what you
can.

What governs it is my choice of the 32 bit version of WGET which only
works in Windows.

The selection of the 32 bit version of WGET was perfect. It's elsewhere that
you erred.

That's because F-Prot for DOS is not specified for use on NT based OS.

F-Prot is specified for, but not *guaranteed* to scan all directories under NT
based OS, which is quite different from not specified. I stopped recommending
F-Prot as an "informal" (who invented that misleading definition?) scanner
because of that. Yet F-Prot is still the proper tool for scanning, and
especially to clean, under NT based OS too, by specifying the particular path to
scan (you have to specify the path / directory to F-Prot by its DOS short name,
e.g. \PROGRA~1 for "\program files").

Your above statement is one of the judgement mistakes that you did, that led you
to make further bad selections.

My program is also a user interface for F-Prot for DOS. It also
creates a set of emergency boot disks only applicable for Win 9X/ME

True, and I am aware of it. Yet my comments refer to the program's declared and
main purpose, which is an updater (and not an EBD maker). Subordinating your
design considerations to secondary issues, especially when they contradict the
main purpose, is a gross mistake. Being an engineer you surely know that.

[...]

Boy, you are the thickest and most stubborn SOB I've seen in ages

That too, but there are much more pronounced traits to my qualifications. ;-)

You can't get the info I want for my program from that very limited
and ancient DOS service. I want multiple file dates and I want to
present the LFN to the user. You seem completely locked into just one
of the modes of the F-comp program.

The one that is locked on a false concept is you. So far your F-Comp program
doesn't display long filenames and it never will, for limitations that are
inherent to other parameters in your solution (the selection of the compiler, to
mention one).

That's what I suggest in my Info in the program.

You can do better than that. For example, by changing the way the reference DB
is organized, with less files (use a unified database), in a compact form (in
binary format rather than as text).

Impractical? No. A PITA? Probably. I doubt though that most average
users are interested in checking multiple drives and partitions.

Another judgement mistake. Personally, I don't think that your F-Comp utility
has great use. I can tell that from the usage of the audit feature in our Audit
& Integrity module (it does what your F-Comp program does, plus a few other
"unimportant" things like integrity, and PEI screening). The A&I reports that I
received from users over years had mostly the audit feature OFF. Since A&I was
introduced, eight years ago, I remember having seen less than ten reports in
which audit was ON. Most A&I reports from users cover "all local drives", only
very few concentrate on a specific path / sub-directory.

Which brings me to another deficiency worth fixing in your F-Comp program: When
displaying the list of the available drives for monitoring, then there is no
point including in that list all logical drives, just those that are partitions
on the local hard drives. After all, what point is there to monitoring file
changes on the CD-ROM(s), or RAM-drive? To do that, you could use service 4409h
of INT 21h (IOCTL). To find the drives that you are interested in, test all
drives that pass the call, and reject those that test for 'remote', SUBSTituted,
RAMdrive, or do not allow direct IO. That leaves you with exactly the drives
you need.

Well, I do feel compelled to point out your lies, distortions and
inaccuracies.

Haven't your mom taught you how to conduct a civilized dispute, by carefully and
honestly choosing your accusations?

One other thing for those who may be interested. I noticed that Int
21h service 7143h can either get or set date and time on a file. And
all three sets of date-times can be set. Seems it might be easy for
malicious code to set a early set of dates on its files outside the
range searched by the top selection of F-comp.

I suspected this is the case. A date range search for newer files is
one of these "sometimes useful" heuristics in the case of malware.

For what it's worth, not worth bothering about.

Regards, Zvi

 

[null]

I am well aware of that and mentioned either executable, where appropriate.


Not at all. The discussion is about fixing Fp-up , not Wget.

You have the tail wagging the dog because later versions of FP-UP were
not even characterized as a "updater". I began long ago refering to
F-pup as a emergency download whereby a user could create a set of
emergency disks on a clean Win 9X/ME PC. The download of F-Prot for
DOS and the updating of its DEFs became secondary and a convenience to
the user rather than a prime purpose of the program. Of course, the
F-prot user interface aspect isn't necessary for that end. The program
actually has multiple purposes and uses. To characterize it as just a
updater is false and misleading. Personally, I use both the updater
and user interface aspects. If I was doing av work for users I'd also
use the EBD set creation.

[...]

What does work nicely is the use of your TOGGLMOD to run the FP-UP
program (or any F-Prot updater) in that type of Safe mode. So users do
have this "semi-formal" alternative to update when they're just
partially in deep doodoo and can at least get to this Safe mode. The
obvious problem is that this is not something average users will be
using or doing.

Since you mentioned ToggleMode, then it's a fair example of a DOS utility that
runs in all environments, from pure DOS to the DOS box of *all* Windows
versions. Like your updater, ToggleMode acts as a shell for REGEDIT, among
other things that it does (edit System.ini, for example). Learn from what you
can.

Nothing at all to learn there.

The selection of the 32 bit version of WGET was perfect. It's elsewhere that
you erred.

I did?

F-Prot is specified for, but not *guaranteed* to scan all directories under NT
based OS, which is quite different from not specified.

We've had that discussion before. Frisk does not specify F-Prot for
DOS on NT based OS. You're just giving the reason why it's not.

I stopped recommending
F-Prot as an "informal" (who invented that misleading definition?)

Chris Quirke may have started that "formal" versus "informal"
terminology. Seems to me to be somewhat useful "geek speak" in this
case. I think we know what's meant sufficiently to converse in those
terms without too much misunderstanding.

scanner
because of that. Yet F-Prot is still the proper tool for scanning, and
especially to clean, under NT based OS too, by specifying the particular path to
scan (you have to specify the path / directory to F-Prot by its DOS short name,
e.g. \PROGRA~1 for "\program files").

Well, if that's so then FP-UP would be handy since the user can
conveniently click on folders to scan. As I've said, I have no NT
based OS here for testing.

True, and I am aware of it. Yet my comments refer to the program's declared and
main purpose, which is an updater (and not an EBD maker). Subordinating your
design considerations to secondary issues, especially when they contradict the
main purpose, is a gross mistake. Being an engineer you surely know that.

Addressed that issue above. I can't help it others refer to it as
"just a updater".

[...]

Boy, you are the thickest and most stubborn SOB I've seen in ages

That too, but there are much more pronounced traits to my qualifications. ;-)

For others who may be trying to read this post, there's a confusing
switcheroony starting here back to my F-comp program

The one that is locked on a false concept is you. So far your F-Comp program
doesn't display long filenames and it never will, for limitations that are
inherent to other parameters in your solution (the selection of the compiler, to
mention one).

Huh? Both modes can and do display LFNs. I don't know why the LFN
interrupt services are kinda inconsistent, but IIRC there is a "if
available" clause in their use. In my experience, (I think) they've
always supplied the long form for actual LFNs. And the resulting LFN
display on my prgram is only blank with some, but not all, 8.3 actual
names.

And I've already pointed out that I use the so-called Windows 95
interrupts to get triple date-time info unavailable otherwise.

You can do better than that. For example, by changing the way the reference DB
is organized, with less files (use a unified database), in a compact form (in
binary format rather than as text).

Sure, I could if I wanted to but at this point I don't Right now
I'm giving some thought, now and then, to how I might "harden" the
reference while still maintaining my original (and good) idea of the
program only running on Win 9X/ME. Other than encryption, I've also
considered the option of offering to Save the reference data on
floppy. However, see below. I may not spend amuch more time and effort
on it.

Another judgement mistake. Personally, I don't think that your F-Comp utility
has great use. I can tell that from the usage of the audit feature in our Audit
& Integrity module (it does what your F-Comp program does, plus a few other
"unimportant" things like integrity, and PEI screening). The A&I reports that I
received from users over years had mostly the audit feature OFF. Since A&I was
introduced, eight years ago, I remember having seen less than ten reports in
which audit was ON. Most A&I reports from users cover "all local drives", only
very few concentrate on a specific path / sub-directory.

I really don't think my little util will find much use either and
never did. I wanted to play with some ideas, and I had all kinds of
assembly language modules developed for other programs that I've
written associated with files and file finding, etc. Time will tell
just how much more effort I'll put into it, as such.

Which brings me to another deficiency worth fixing in your F-Comp program: When
displaying the list of the available drives for monitoring, then there is no
point including in that list all logical drives, just those that are partitions
on the local hard drives. After all, what point is there to monitoring file
changes on the CD-ROM(s), or RAM-drive?

It doesn't list CD ROMs or make them an option.

To do that, you could use service 4409h
of INT 21h (IOCTL). To find the drives that you are interested in, test all
drives that pass the call, and reject those that test for 'remote', SUBSTituted,
RAMdrive, or do not allow direct IO. That leaves you with exactly the drives
you need.

I didn't though filter out RAM drive. I have developed methods and
assembly language modules for this sort of thing. I'll take a look at
4409H since I don't recall offhand whether I use it or not. Thanks.


Art
http://www.epix.net/~artnpeg