Win98SE, UTF-8 and Eudora
T0M
I'm still using Windows 98SE and Eudora v7.1.0.9.
Eudora works very well except with message using UTF-8, where accents
are not well displayed.
Is there a solution to configure Eudora to use UTF-8 for displaying my
emails or anything esle I can do, knowing that Win98SE is not UTF-8
friend (I believe) ?
tnx in advance
T0M
--
Sorry if I don't answer quickly but I can't be online each day
Wilfried Hennings
>I'm still using Windows 98SE and Eudora v7.1.0.9.
>Eudora works very well except with message using UTF-8, where accents
>are not well displayed.
>
>Is there a solution to configure Eudora to use UTF-8 for displaying my
>emails or anything esle I can do, knowing that Win98SE is not UTF-8
>friend (I believe) ?
Eudora isn't able to display UTF-8 either, even not in newer Windows
versions.
But there is a Eudora plugin at
http://www.windharp.de/software/utf8iso.htm
which can decode those UTF-8 characters which are available in the
current Windows character set.
HTH
Wilfried Hennings
Please reply in the newsgroup, the reply address is invalid.
Unknown
<inv...@invalid.invalid> wrote:
> But there is a Eudora plugin at
> http://www.windharp.de/software/utf8iso.htm
That was a good one, thanx!!!
Unknown
Why must I go Edit > Message Plug-ins > UTF8->ISO each time that I
want to use the plug-in ?
Wilfried Hennings
Html formatted messages aren't decoded by default, maybe this is your
problem.
Go to menu Special - Message Plug-ins Settings -
(scroll down to) UTF8Iso and click
You'll see a window with three checkboxes.
Check the "Process html messages" box
and perhaps also the "Decode MIME 64".
T0M
>>Eudora isn't able to display UTF-8 either, even not in newer Windows
>>versions.
>>But there is a Eudora plugin at
>>http://www.windharp.de/software/utf8iso.htm
>>which can decode those UTF-8 characters which are available in the
>>current Windows character set.
>>
>>HTH
>>
>>Wilfried Hennings
>>Please reply in the newsgroup, the reply address is invalid.
Thank you so much Wilfried !
T0M
Franc Zabkar
<inv...@invalid.invalid> put finger to keyboard and composed:
I just received a HTML message with a UTF8 subject. Eudora crashed
when the OS tried to create a HTML file using the subject as a
template for a filename. The problem was that the subject contained
UTF-8 encoded characters that are illegal when used in filenames.
The fix was to locate the offending message (a .RCV file) in the Spool
directory and edit the offending subject line with Notepad.
I'm using Win98SE and Eudora 7.1.0.9.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
John H Meyers
> I just received a HTML message with a UTF8 subject. Eudora crashed
> when the OS tried to create a HTML file using the subject as a
> template for a filename. The problem was that the subject contained
> UTF-8 encoded characters that are illegal when used in filenames.
>
> The fix was to locate the offending message (a .RCV file) in the Spool
> directory and edit the offending subject line with Notepad.
>
> I'm using Win98SE and Eudora 7.1.0.9.
A message _subject_ should never be used as a filename,
and I suspect that neither files in the Spool directory
nor "send to browser" files in a Windows local "Temp" directory
are ever given such names by Eudora itself.
Do you think that the UTF8 plugin itself creates an HTML file
having the subject as a file name?
I do recall another possibility:
Eudora does a "weird thing"
when receiving _unnamed_ attachments, which is
that some designer's imagination went into overdrive,
and decided to give the _attachment_ a file name
made from the message subject,
apparently without taking sufficient care
to prevent using invalid names:
"Re: RTF attachment name - caught in the act!" 2007.05.20
http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/dfd4826ba65ba5bb
So it might be interesting for you to see
whether the offending message does in fact
contain any unnamed attachment, which needs a name
to be stored into the "attach" or "embedded" directory;
if so, then giving the attachment a definite name
(by augmenting the attachment's own internal headers)
might also take care of the issue,
as would encouraging the sender(s) to do the same.
IIRC, the recommended plugin does not try to deal with
UTF8-encoded subjects, for what I think was a good reason
(although I forget what that was :)
and should therefore, at the very same time,
probably not be guilty of trying to use a subject as a filename.
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Tue, 26 Aug 2008 17:15:22 -0500, Franc Zabkar wrote:
>
>> I just received a HTML message with a UTF8 subject. Eudora crashed
>> when the OS tried to create a HTML file using the subject as a
>> template for a filename. The problem was that the subject contained
>> UTF-8 encoded characters that are illegal when used in filenames.
>>
>> The fix was to locate the offending message (a .RCV file) in the Spool
>> directory and edit the offending subject line with Notepad.
>>
>> I'm using Win98SE and Eudora 7.1.0.9.
>
>A message _subject_ should never be used as a filename,
>and I suspect that neither files in the Spool directory
>nor "send to browser" files in a Windows local "Temp" directory
>are ever given such names by Eudora itself.
>
>Do you think that the UTF8 plugin itself creates an HTML file
>having the subject as a file name?
I'm using a HTML plugin that converts HTML messages to files. However,
I still had the same problem with UTF-8 subjects before I discovered
this plugin.
>I do recall another possibility:
>
>Eudora does a "weird thing"
>when receiving _unnamed_ attachments, which is
>that some designer's imagination went into overdrive,
>and decided to give the _attachment_ a file name
>made from the message subject,
>apparently without taking sufficient care
>to prevent using invalid names:
>"Re: RTF attachment name - caught in the act!" 2007.05.20
>http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/dfd4826ba65ba5bb
>
>So it might be interesting for you to see
>whether the offending message does in fact
>contain any unnamed attachment, which needs a name
>to be stored into the "attach" or "embedded" directory;
>if so, then giving the attachment a definite name
>(by augmenting the attachment's own internal headers)
>might also take care of the issue,
>as would encouraging the sender(s) to do the same.
Nothing in either of those directories, although eudora.log suggests
that Eudora was trying to write to the Attach directory. See end of
post.
>IIRC, the recommended plugin does not try to deal with
>UTF8-encoded subjects, for what I think was a good reason
>(although I forget what that was :)
>and should therefore, at the very same time,
>probably not be guilty of trying to use a subject as a filename.
This was one message that crashed an earlier version of Eudora:
http://www.users.on.net/~fzabkar/Eudora/4735205E.RCV
I haven't tried it with my current version, though. Ironically it was
a Christmas greeting.
This is an old post where I tried to describe the problem:
http://groups.google.com/group/comp.mail.eudora.ms-windows/browse_thread/thread/470e1b9d4c3c91e/a132758bc2263af1?lnk=st&q=#a132758bc2263af1
http://preview.tinyurl.com/5kngyd
The following are four current examples.
===================================================================
Subject: BMW serije 3. Čas je, da podle�e
te �elji.
X-NotAscii: charset=windows-1250
X-HTML-Message-Converted: c:\FZwork\Eudora\HTML Messages\BMW serije 3.
Čas je, da podle�.htm
The above file does not exist. Notice there is no "file://" in the
URI. This message did not crash Eudora.
===================================================================
Subject: CRT\RT29FA33RQ sevice manual
X-NotAscii: charset=us-ascii
X-HTML-Message-Converted: "file://c:\FZwork\Eudora\HTML
Messages\CRTRT29FA33RQ sevice manual.htm"
The above file does exist. No crash.
===================================================================
Subject: LG CRT/LCD/Plasma/Projection TV service manuals
X-NotAscii: charset=windows-1252
X-HTML-Message-Converted: "file://c:\FZwork\Eudora\HTML Messages\LG
CRTLCDPlasmaProjection TV.htm"
The above file does exist. No crash.
===================================================================
Subject: Trio ze za 30 EUR
X-NotAscii: charset=utf-8
X-HTML-Message-Converted: "file://c:\FZwork\Eudora\HTML Messages\Trio
ze za 30 EUR.htm"
The above file does exist.
===================================================================
The last example was the one that crashed Eudora. The edited
non-crashing version is shown. Before I edited it, the "z" in "ze" was
a UTF-8 encoded representation of the Slovenian character "zh"
(pronounced as in "Zhivago"). The subject line had "=" and "?"
characters but the log shows "\032". It appears that the backslash was
the reason for the file creation problem. Sorry, I didn't retain a
record of the original format of the message.
This is an excerpt from eudora.log:
MAIN 16: 0.06 in...@teledat.si, Trio \032e za 30 EUR
MAIN 128: 0.06 LOGNULL GetEMSHeaders() 1 JJFileMT::Seek(292337)
MAIN 128: 0.06 LOGNULL GetEMSHeaders() 2 JJFileMT::Seek(294262)
MAIN 8: 0.06 Dialog: "Could not open the file
D:\FZwork\Eudora\Attach\Trio \032e za 30 EUR.ems for writing\r\n"
MAIN 8: 0.06 Dialog: "\r\n"
MAIN 8: 0.06 Dialog: "Cause: No such file or directory exists.
(2)"
MAIN 8: 0.10 Dialog: "Dismissed with 1"
John H Meyers
> This is an old post where I tried to describe the problem:
http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/a132758bc2263af1
http://groups.google.com/groups?selm=15lur1l750mlfn2vm...@4ax.com
[alternate URLs]
The log quoted in that post contains:
MAIN 8: 0.08 Dialog: "Could not open the file
D:\FZwork\Eudora\Attach\Vo\032\100\011ilo.ems for writing\r\n"
MAIN 8: 0.08 Dialog: "\r\n"
MAIN 8: 0.08 Dialog: "Cause: No such file or directory exists.
An "EMS" attachment accompanies S/MIME (or perhaps even PGP/GPG) content;
I don't know whether those also get treated that way.
It might be of interest to know whether the same happens
either with or without the UTF8 plugin
(and which plugin, which version, and are there any other plugins involved?),
because otherwise there could be "too many suspects" to narrow the hunt
for the guilty culprit, which could of course still be Eudora :)
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Wed, 27 Aug 2008 00:02:23 -0500, Franc Zabkar wrote:
I believe the first incident predates my installation of the UTF8
plugin as well.
In fact the creation dates of the UTF-ISO and HTML Handler plugins are
25/11/2006 and 14/01/2007, respectively, whereas my old post is dated
Jan 8, 2006. So the fault does appear to lie with Eudora itself.
John H Meyers
> I believe the first incident predates my installation of the UTF8
> plugin as well.
>
> In fact the creation dates of the UTF-ISO and HTML Handler plugins are
> 25/11/2006 and 14/01/2007, respectively, whereas my old post is dated
> Jan 8, 2006. So the fault does appear to lie with Eudora itself.
It may still relate only to the "unnamed" attachments,
and not to all messages having UTF8 subjects
(of which I have received many, without incident).
It is possible to pre-screen all messages on a POP server,
by downloading "headers only," or even by setting
"Skip messages over [nn]K," which will generally
not yet download any attachments, hence not attempt
to use the subject as a name for any unnamed attachments.
A Gmail account can pull in mail from any POP server
(with or without deleting fetched mail from POP server),
and will simply give the name "noname" to any un-named attachment.
"Eudora 8" (Thunderbird) will probably solve it, if it's ever finished :(
Best wishes.
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Wed, 27 Aug 2008 05:27:09 -0500, Franc Zabkar wrote:
I only receive these problematic emails on rare occasions, not
frequently enough to warrant a change of practice. But thanks for the
ideas anyway. BTW, you are welcome to copy my .RCV file to your Spool
directory, if you are prepared for a crash. I suggest you compact your
Inbox and make a copy of it before experimenting with my message,
though. I have yet to lose any work, but you can never be certain.
John H Meyers
> you are welcome to copy my .RCV file to your Spool directory,
> if you are prepared for a crash.
No crash!
http://img237.imageshack.us/my.php?image=euclip1xe8.jpg
How tested:
o Unmodified original installation of Eudora 7.1.0.9 program files (no plugins).
o Started Eudora with empty original "Data" folder.
o Closed Eudora.
o Copied file "4735205E.RCV" to "spool" subfolder.
o Opened Eudora, specified a POP server (empty inbox), checked mail once.
I'd be glad to try other suggested tests, or anyone can do it.
BTW, a simple way to start Eudora using any folder at all as the "Data" folder
is to drag that folder to either the Eudora.exe program itself or to
a Eudora.exe shortcut having no added path in its "Target" (command line).
One can thus create empty original folders to test and then "throw away,"
at no risk to existing "real life" mail.
As an afterthought, I copied the same RCV file again to the "spool" folder,
and re-opened it with my "fully loaded" version of Eudora
(Paid mode, plugins including UTF8ISO, etc.) with similar uneventful result:
now I simply have two identical copies of the message.
If course, the message was not actually downloaded via POP,
so I don't know whether UTF8ISO itself handled it directly from the RCV file.
A third repetition after enabling HTML in UTF8ISO acted again the same.
Got any more RCV files?
Or, send UTF8 messages to account utf8iso with domain miu ddott edu
(let me know if you do, as I won't bother checking mail otherwise).
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Thu, 28 Aug 2008 01:12:32 -0500, Franc Zabkar wrote:
>
>> you are welcome to copy my .RCV file to your Spool directory,
>> if you are prepared for a crash.
>
>No crash!
>http://img237.imageshack.us/my.php?image=euclip1xe8.jpg
>
>How tested:
>
>o Unmodified original installation of Eudora 7.1.0.9 program files (no plugins).
>o Started Eudora with empty original "Data" folder.
>o Closed Eudora.
>o Copied file "4735205E.RCV" to "spool" subfolder.
>o Opened Eudora, specified a POP server (empty inbox), checked mail once.
>
>I'd be glad to try other suggested tests, or anyone can do it.
I tried the same message again after copying it to my Spool directory
... and it crashed Eudora again.
See my screen dumps at http://www.users.on.net/~fzabkar/Eudora/
>BTW, a simple way to start Eudora using any folder at all as the "Data" folder
>is to drag that folder to either the Eudora.exe program itself or to
>a Eudora.exe shortcut having no added path in its "Target" (command line).
>
>One can thus create empty original folders to test and then "throw away,"
>at no risk to existing "real life" mail.
>
>As an afterthought, I copied the same RCV file again to the "spool" folder,
>and re-opened it with my "fully loaded" version of Eudora
>(Paid mode, plugins including UTF8ISO, etc.) with similar uneventful result:
>now I simply have two identical copies of the message.
FWIW, I'm using a paid version as well.
>If course, the message was not actually downloaded via POP,
>so I don't know whether UTF8ISO itself handled it directly from the RCV file.
>
>A third repetition after enabling HTML in UTF8ISO acted again the same.
>
>Got any more RCV files?
I don't think so.
>Or, send UTF8 messages to account utf8iso with domain miu ddott edu
>(let me know if you do, as I won't bother checking mail otherwise).
- Franc Zabkar
John H Meyers
> See my screen dumps at http://www.users.on.net/~fzabkar/Eudora/
Looking first at the RCV file, it's a very straightforward
"Multipart/alternative" message, which means it was sent
in both "plain text" and HTML -- with each part
(as well as the subject) having UTF8 encoding.
Note that there are no "attached" or "embedded" files in that message
(all images are externally fetched). BTW, for a 2-3 year old message
to still fetch them means that the company is more stable than many others :)
As to crashing, is this when trying in a brand new (initially empty)
mail data folder, or only in an old folder that's long been in use?
One thing that makes me suspicious is that the file
which "Can't be opened for writing" is both in the "Attach"
directory and has an extension ".ems" -- this makes me wonder
whether it is some plugin that is trying to write this file,
and whether that plugin may not really be part of Eudora at all?
(it's not only Eudora which can have bugs, I'm told :)
After all the times I put your RCV file into _my_ "spool" folder
and it was simply processed normally, there is no file
with ".ems" extension left anywhere in _my_ mail "Data" directory,
neither in the "Attach" folder nor anywhere else.
Do any of the following sound like potential clues?
"The Eudora Extended Message Services API (EMS API) is designed
so that third party plug-ins can be added to Eudora by the end user."
"What the EMS API Really Does"
http://www.eudora.com/developers/emsapi/emswhat.html
"Eudora EMS API Developer's Manual Version 2"
http://www.eudora.com/developers/emsapi/emsdoc.html
"Windows EMS API SDK v1b4 Function Overview"
http://www.eudora.com/developers/emsapi/SDK.html
Other documents:
http://www.eudora.com/developers/emsapi/
Is it possible either to move all external plugins elsewhere,
or to make a "clean" install of another copy (or version)
into a different "programs" path, and see what happens
using the "clean" version?
You also previously wrote:
> I'm using Win98SE and Eudora 7.1.0.9
Well, Qualcomm did change its original "Readme"
and finally said that Eudora v7109 requires Windows 2000 or XP;
there are known issues involving dial-up and address book,
and beyond that, one would not know whether there are any more.
If you install version 6.2.5.6, say, into a different
"programs" path, then you could try the same experiment
using a never-used new folder, and optionally your "everyday" folder.
"Detective work" is often said to require "shoe leather,"
which in this case might mean some series of experiments
to attempt to isolate where the problem really is.
All that I can say is that I can not reproduce the problem
with 7.1.0.9 on Windows XP. No problem with "clean" installation,
nor with an installation having my particular set of plugins.
But of course, YMMV :(
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Thu, 28 Aug 2008 15:45:28 -0500, for Franc Zabkar
Thanks for the feedback. Strangely I traced the problem to Brana's
HTML Handler plugin <egg on face>. This doesn't gel with the dates of
the files, though. <shrug>
The message decoded without incident when I renamed the html.dll file
(ver 3,1,0,1) in the Plugins folder. However, I noticed that renaming
the Esp.dll file on its own still resulted in a crash. I would have
thought that Brana's plugin relied on Eudora's EMS API, but apparently
not. Maybe Brana's plugin incorporates the relevant code from the EMS
API? FWIW, I see "ems" text strings in html.dll.
BTW, there is no .ems file in the Attach folder even after I edit the
problematic subject line. Could these .ems files be temporary files
created by the EMS API for use by those plugins that need them? If so,
could it be a bug in the EMS API code that shows up in Win9x but not
in XP? Is there a way to trap and view the .ems file before it is
deleted?
BTW, I also tried creating the following folders (because it appeared
that something was looking for one or more of them - see eudora.log)
but still couldn't avoid a crash:
D:\FZwork\Eudora\Attach\Vo
D:\FZwork\Eudora\Attach\Vo\032
D:\FZwork\Eudora\Attach\Vo\032\100
... and later I added ...
D:\FZwork\Eudora\Attach\Vo\032\100\011
D:\FZwork\Eudora\Attach\Vo\032\100\011ilo.ems
As before, this is the relevant excerpt from eudora.log:
MAIN 8: 0.01 Dialog: "Could not open the file
D:\FZwork\Eudora\Attach\Vo\032\100\011ilo.ems for writing\r\n"
MAIN 8: 0.01 Dialog: "\r\n"
MAIN 8: 0.01 Dialog: "Cause: No such file or directory exists.
(2)"
In answer to your question re the target mail folder, I'm using an old
folder, not a new empty one.
John H Meyers
> I traced the problem [crash on bad filename when there is UTF8
> in Subject of Multipart/Alternative (plain text and HTML) message]
> to Brana's HTML Handler plugin.
> The message decoded without incident when I renamed the html.dll file
> (ver 3,1,0,1) in the Plugins folder.
Eureka!
> Could these .ems files be temporary files
> created by the EMS API for use by those plugins that need them?
I suppose you could ask Brana.
> In answer to your question re the target mail folder,
> I'm using an old folder, not a new empty one.
I suspect it wouldn't make a difference,
though one could always try a "new" folder just to make sure.
---
"Well, it's no use talking about it now," said Sam.
"It's over, and can't be helped, and that's one consolation,
as they always says in Turkey, ven they cuts the wrong man's head off."
http://www.dickens-literature.com/The_Pickwick_Papers/22.html
--
Franc Zabkar
<jhme...@nomail.invalid> put finger to keyboard and composed:
>On Fri, 29 Aug 2008 00:28:51 -0500, Franc Zabkar wrote:
>
>> I traced the problem [crash on bad filename when there is UTF8
>> in Subject of Multipart/Alternative (plain text and HTML) message]
>> to Brana's HTML Handler plugin.
>
>> The message decoded without incident when I renamed the html.dll file
>> (ver 3,1,0,1) in the Plugins folder.
>
>Eureka!
>
>> Could these .ems files be temporary files
>> created by the EMS API for use by those plugins that need them?
>
>I suppose you could ask Brana.
I've sent her an email. However, I think I have confirmed this
behaviour myself.
After renaming the subject to "Voscilo4", here is FileMon's filtered
output:
7:49:04 AM Eudora:FFFAC36D Attributes
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS NOTFOUND GetAttributes
7:49:04 AM Eudora:FFFAC36D Open
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS CREATENEW OPENEXISTING
WRITEONLY DENYNONE
7:49:04 AM Eudora:FFFAC36D Write
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Offset: 0 Length: 4096
7:49:04 AM Eudora:FFFAC36D Write
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Offset: 4096 Length:
4096
7:49:04 AM Eudora:FFFAC36D Write
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Offset: 8192 Length:
3905
7:49:04 AM Eudora:FFFAC36D Close
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS CLOSE_FINAL
7:49:04 AM Eudora:FFFAC36D Open
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS OPENEXISTING READWRITE
DENYNONE
7:49:04 AM Eudora:FFFAC36D Read
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Offset: 0 Length: 4095
7:49:04 AM Eudora:FFFAC36D Close
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS CLOSE_FINAL
7:49:04 AM Eudora:FFFAC36D Open
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS OPENEXISTING READONLY
DENYREADWRITE
7:49:04 AM Eudora:FFFAC36D Seek
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Beginning Offset: 0 /
New offset: 0
7:49:04 AM Eudora:FFFAC36D Seek
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Beginning Offset: 0 /
New offset: 0
7:49:04 AM Eudora:FFFAC36D Seek
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS End Offset: 0 / New
offset: 0
7:49:04 AM Eudora:FFFAC36D Seek
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Beginning Offset: 0 /
New offset: 0
7:49:04 AM Eudora:FFFAC36D Read
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Offset: 0 Length:
12097
7:49:04 AM Eudora:FFFAC36D Close
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS CLOSE_FINAL
7:49:04 AM Eudora:FFFAC36D Attributes
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS GetAttributes
7:49:04 AM Eudora:FFFAC36D FindOpen
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS Voscilo4.ems
7:49:04 AM Eudora:FFFAC36D FindClose
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS
7:49:04 AM Eudora:FFFAC36D Delete
D:\FZWORK\EUDORA\ATTACH\VOSCILO4.EMS SUCCESS
FileMon is available here:
http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
http://download.sysinternals.com/Files/Filemon.zip
BTW, I'm aware that Process Monitor is better, but it doesn't run
under Win98:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
http://download.sysinternals.com/Files/ProcessMonitor.zip