Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Installing Eudora 5.1 on new PC with Windows 7
379 views
Skip to first unread message
Lew Siegel
May 15, 2012, 12:09:29 PM5/15/12
to
I have been using Eudora 5.1 on a PC with XP. I just purchased a PC
with Windows 7 Pro 64 bit and would like to try to continue using 5.1.
From reading some posts, I think I got the gist of the install
process, but if there is a step by step guide it would be greatly
apprecaited.
One thing I did not understand was to move the "data" file from the XP
machine to the new machine. I looked under the "documents and settings/
UserName/applicationdata" folder and could not find a folder named
"data" or Qualcom or Eudora. Was this only for later versions? All of
the 5.1 files seem to be under ProgramFiles/Qualcom\Eudora.
What files should be moved over to the new installation?
I understand it will install to a differently named directory, e.g.
Program Files (x86) and that as a result old attachments will no
longer be attached.
Thanks in adavnce for any guidance or help.
Lew Siegel
with Windows 7 Pro 64 bit and would like to try to continue using 5.1.
From reading some posts, I think I got the gist of the install
process, but if there is a step by step guide it would be greatly
apprecaited.
One thing I did not understand was to move the "data" file from the XP
machine to the new machine. I looked under the "documents and settings/
UserName/applicationdata" folder and could not find a folder named
"data" or Qualcom or Eudora. Was this only for later versions? All of
the 5.1 files seem to be under ProgramFiles/Qualcom\Eudora.
What files should be moved over to the new installation?
I understand it will install to a differently named directory, e.g.
Program Files (x86) and that as a result old attachments will no
longer be attached.
Thanks in adavnce for any guidance or help.
Lew Siegel
Message has been deleted
John H Meyers
May 15, 2012, 6:57:07 PM5/15/12
to
On 5/15/2012 4:23 PM, Dennis Lee Bieber wrote:
> Eudora 7.1 doesn't add a "Message-ID:" header
The header is generated and saved in Out.mbx as usual,
but isn't sent to the SMTP server -- this was done
to correct a bug, which is that "Send Again" was
repeating the same ID, which is against the rule
saying that every separately sent message must have a unique ID.
When the local SMTP server receives a message
which doesn't already contain a "Message-ID:" header,
almost every SMTP server generates a unique "Message-ID:" for you,
and thus solves the problem _correctly_ (note that you can edit
content when using "Send Again," so in many cases the next message
is not even a duplicate, but whether or not the _content_
is duplicated, a _new_ "Message-ID:" is supposed to accompany
any message sent in a different SMTP session, ideally
in all the history of internet messages ever created
(this is why time stamps are often used in the Message-ID).
--
> Eudora 7.1 doesn't add a "Message-ID:" header
The header is generated and saved in Out.mbx as usual,
but isn't sent to the SMTP server -- this was done
to correct a bug, which is that "Send Again" was
repeating the same ID, which is against the rule
saying that every separately sent message must have a unique ID.
When the local SMTP server receives a message
which doesn't already contain a "Message-ID:" header,
almost every SMTP server generates a unique "Message-ID:" for you,
and thus solves the problem _correctly_ (note that you can edit
content when using "Send Again," so in many cases the next message
is not even a duplicate, but whether or not the _content_
is duplicated, a _new_ "Message-ID:" is supposed to accompany
any message sent in a different SMTP session, ideally
in all the history of internet messages ever created
(this is why time stamps are often used in the Message-ID).
--
John H Meyers
May 15, 2012, 9:00:56 PM5/15/12
to
On 5/15/2012 11:09 AM, Lew Siegel wrote:
> I have been using Eudora 5.1 on a PC with XP. I just purchased a PC
> with Windows 7 Pro 64 bit and would like to try to continue using 5.1
Are you still trying to play your 45rpm phonograph record collection
> I have been using Eudora 5.1 on a PC with XP. I just purchased a PC
> with Windows 7 Pro 64 bit and would like to try to continue using 5.1
on your MP3 player and mobile phone?
Have a free "Paid" (and ultimately improved) 7.1,
courtesy of Qualcomm:
<http://eudorabb.qualcomm.com/showthread.php?t=16492>
If you'd like to read about much (but not even all)
that you've meanwhile been missing, here are the cumulative Release Notes:
<http://www.eudora.com/download/eudora/windows/7.1/RelNotes.txt> 6.0 to 7.1
<http://www.eudora.com/download/eudora/windows/6.0/RelNotes.txt> 5.0 to 6.0
> One thing I did not understand was to move the "data" file from the XP
> machine to the new machine. I looked under the "documents and settings/
> UserName/applicationdata" folder and could not find a folder named
> "data" or Qualcom or Eudora. Was this only for later versions?
> All of the 5.1 files seem to be under ProgramFiles/Qualcom\Eudora.
selected either at the time of original program installation
or at any subsequent time that you want to either
move existing data or create one or more new data folders.
> What files should be moved over to the new installation?
then you can open that folder on Win2000 thru Win7+
using WindowsKey+R to get a "Run" dialog box,
then type or paste exactly this: %AppData%\Qualcomm\Eudora
If your settings (Eudora.ini) and mail (In.mbx) etc.
are instead stored with Eudora's program files,
then the program files folder itself is your old "Data" folder.
Either way, you can copy EVERYTHING from your old data folder
to your new Data folder on Win7, provided that when you install on Win7,
you tell the installer that you want to keep your data files
either in "User's Application Data Folder"
or in a folder that you've created on some other drive,
but NOT where "program files" go in the new system.
Launching Eudora once then ensures that the new "Data" folder
is created in the correct place. You may then close the new Eudora,
then copy ALL your old data files (and subfolders) into the new Data folder.
Doing it this way ensures that you can not forget anything
that you might later realize you needed. Any extra files copied
are generally ignored, and thus don't cause any bother.
> I understand it will install to a differently named directory, e.g.
> Program Files (x86) and that as a result old attachments will no
> longer be attached.
(under the _Data_ directory) then old attachments
will remain attached. If old attachments that were at any other explicit path
are moved into the new installation's attachment directory,
then old attachments will also remain attached.
Even weird cases of scattered attachments might be repaired using
"Mailbox Tools For Eudora" by Brana Bujenovic:
<http://www.drivehq.com/web/brana/mte.htm>
--
John H Meyers
May 16, 2012, 12:44:58 AM5/16/12
to
On 5/15/2012 8:00 PM, John H Meyers wrote:
LS:
Within an incoming message, you see a complete path
to the exact original location of an attachment,
on the old computer, e.g.:
C:\Program Files\...\Eudora\Attach\myfile.xyz
When you move all your data to the new (Win7) computer,
you have followed the good advice to keep your data files elsewhere
(nowhere near, nor under, any "program files" location).
Therefore, the new default attachments folder on the new computer
is not at the same path as is stored in the old message.
So, what does Eudora do, if you ask it to open the attachment?
My understanding is that it then takes just the basic file name
(myfile.xyz) and looks for a file having that name
in the new default attachments folder,
so if in fact you have moved all old attachments
into the new default folder, they will still be found and can be opened
(gee, don't you admire how smart those Eudora developers must have been?)
Some of the other optional functions may not continue working on old attachments,
e.g. "Explore attachment" or "Delete attachment" may still fail,
if those functions attempt to open only the full path to the original directory.
However, Brana's "Mailbox Tools for Eudora" may be able to actually
rewrite the full path names in old messages for you -- this is not something
you should try to do by editing a mailbox yourself, because you would then
generally be lengthening or shortening some messages, which would
throw the entire table of contents (.toc file) out of sync with messages,
but Brana's function would know how to automatically keep everything in sync
(gee, don't you admire Brana for creating such wonderful and useful tools?)
Brana's own site always has the latest version of these tools,
whereas other distribution sites may still have older versions.
Another tool in this same package does wonders for repairing
a TOC that's been lost and rebuilt by Eudora, which otherwise
loses a lot of information, such as whether each message was
originally incoming or outgoing (which in turn affects the "Who" and "Date" columns),
or had an attachment, or was marked as "sent" in the "Out" mailbox, etc.
Brana was generous enough to offer free download of fully working tools,
which can be applied to any one mailbox at a time, but of course,
once you appreciate their value, you'll no doubt desire to support them
by donating the small fee for a completely unrestricted (multi-mailbox) license
(and perhaps some direct support, if you need any).
--
LS:
>> I understand it will install to a differently named directory, e.g.
>> Program Files (x86) and that as a result old attachments will no
>> longer be attached.
JHM:
>> Program Files (x86) and that as a result old attachments will no
>> longer be attached.
> If the attachment directory defaults to "Attach" as usual,
> (under the _Data_ directory) then old attachments
> will remain attached. If old attachments that were at any other explicit path
> are moved into the new installation's attachment directory,
> then old attachments will also remain attached.
Let's explain further how this works.
> (under the _Data_ directory) then old attachments
> will remain attached. If old attachments that were at any other explicit path
> are moved into the new installation's attachment directory,
> then old attachments will also remain attached.
Within an incoming message, you see a complete path
to the exact original location of an attachment,
on the old computer, e.g.:
C:\Program Files\...\Eudora\Attach\myfile.xyz
When you move all your data to the new (Win7) computer,
you have followed the good advice to keep your data files elsewhere
(nowhere near, nor under, any "program files" location).
Therefore, the new default attachments folder on the new computer
is not at the same path as is stored in the old message.
So, what does Eudora do, if you ask it to open the attachment?
My understanding is that it then takes just the basic file name
(myfile.xyz) and looks for a file having that name
in the new default attachments folder,
so if in fact you have moved all old attachments
into the new default folder, they will still be found and can be opened
(gee, don't you admire how smart those Eudora developers must have been?)
Some of the other optional functions may not continue working on old attachments,
e.g. "Explore attachment" or "Delete attachment" may still fail,
if those functions attempt to open only the full path to the original directory.
However, Brana's "Mailbox Tools for Eudora" may be able to actually
rewrite the full path names in old messages for you -- this is not something
you should try to do by editing a mailbox yourself, because you would then
generally be lengthening or shortening some messages, which would
throw the entire table of contents (.toc file) out of sync with messages,
but Brana's function would know how to automatically keep everything in sync
(gee, don't you admire Brana for creating such wonderful and useful tools?)
Brana's own site always has the latest version of these tools,
whereas other distribution sites may still have older versions.
Another tool in this same package does wonders for repairing
a TOC that's been lost and rebuilt by Eudora, which otherwise
loses a lot of information, such as whether each message was
originally incoming or outgoing (which in turn affects the "Who" and "Date" columns),
or had an attachment, or was marked as "sent" in the "Out" mailbox, etc.
Brana was generous enough to offer free download of fully working tools,
which can be applied to any one mailbox at a time, but of course,
once you appreciate their value, you'll no doubt desire to support them
by donating the small fee for a completely unrestricted (multi-mailbox) license
(and perhaps some direct support, if you need any).
--
Message has been deleted
John H Meyers
May 16, 2012, 2:04:19 PM5/16/12
to
On 5/16/2012 9:07 AM, Dennis Lee Bieber wrote:
> the list address being in both "to" and "cc" fields
It's an SMTP server's job to eliminate repetitions
of identical recipient addresses associated with any single message.
However, SMTP servers do not even look at headers
to determine recipients -- they heed only the
"RCPT TO:" commands sent in SMTP protocol,
before the message data (headers+body) is transmitted,
and they are still supposed to eliminate redundant addresses
among all the RCPT TO commands.
Message ID's are also not supposed to play any role in this.
The more usual reasons why a message is received more than once
is that some NON-identical addresses happen to represent
the same final destination mailbox, commonly due to
forwarding of one address to the same mailbox as another address.
Human beings are, however, pretty much always involved
in programming, and they don't always manage to do
what their job assignments and rules tell them to do :)
--
> the list address being in both "to" and "cc" fields
It's an SMTP server's job to eliminate repetitions
of identical recipient addresses associated with any single message.
However, SMTP servers do not even look at headers
to determine recipients -- they heed only the
"RCPT TO:" commands sent in SMTP protocol,
before the message data (headers+body) is transmitted,
and they are still supposed to eliminate redundant addresses
among all the RCPT TO commands.
Message ID's are also not supposed to play any role in this.
The more usual reasons why a message is received more than once
is that some NON-identical addresses happen to represent
the same final destination mailbox, commonly due to
forwarding of one address to the same mailbox as another address.
Human beings are, however, pretty much always involved
in programming, and they don't always manage to do
what their job assignments and rules tell them to do :)
--
0 new messages