I'm gonna raise a level or two above my "pay-grade" and talk about the
elephant in the room. With which I mean the possibility that making
Eudora/Hermes compile and run is impossible, or indeed infeasable, for
(possibly?) two programmers who doesn't even devote a job-like attention to
the task but jump in and out at their whims and other social contracts they
might have. (I'm talking for myself mostly, but I'm sure Mr. Maclean can
nod in recognision, if not agreement.)
A proper company would have a guy who foretells the future. I forget what
his job-description is, but it could, likely, be "Corporate Oracle".
Allow me to be the "Corporate Oracle",or, indeed, "The Devil's Advocate"
(See tvtropes.org for funny exposition) for a moment and tell you it can't
be done and/or it has no future.
(You saw the maximum MFC version Stingray would work with and the message
they built in, asking you to ask for an update to pay more for. I've made
sure you've seen the insane inline assembler debugging embedded. Also, the
warning that this code wont survive a 64bit transition!)
No matter how you approach it, this code is gonna get obsolete soon.
I'm sorry. Noone likes the messenger carrying bad news, but here I am with
the full depeche ready to hit the fan..
I realise you pay a fortune for this program, but why?, If outlook is more
or less built into W$ why don't you use this or a combination of other
programs tailored to meet the platform in question. Be it M$ or MAC or
POSIX.
Have the users of Eudora/Hermes gotten so stuck in their ways that they
can't transition to a "new way of doing things".
What I mean is that, as Mr. Matavka has seen, mail functionality is built
into M$ examples. A full outlook clone with proper language support is
build into the, so called, "Simple MAPI".
Using OLE to transfer data to an forth this client program may be possible,
but it's a lot of work. Realistically it would be more feasable to hide the
server program Hermes/Eudora and let M$ handle it all.
I realise you're not all using the client for "personal" purposes, an as
such, the free use clauses won't apply. Bt there must be a way aroun that
using several tools.
Has anyone been down this road?
Cordially (and in the hope of not getting slaughtered outright :) ),
Søren.
PS: I'm got gonna hit Local TV soon and those of you with half a brain, and
a somewhere decent command of Danish (This will be my rescue. :) ) will
realise who's "messing around" with your code and/or seeing elephants.
I'm gonna raise a level or two above my "pay-grade" and talk about the
elephant in the room. With which I mean the possibility that making
Eudora/Hermes compile and run is impossible, or indeed infeasable, for
(possibly?) two programmers who doesn't even devote a job-like attention to
the task but jump in and out at their whims and other social contracts they
might have. (I'm talking for myself mostly, but I'm sure Mr. Maclean can
nod in recognision, if not agreement.)
A proper company would have a guy who foretells the future. I forget what
his job-description is, but it could, likely, be "Corporate Oracle".
Allow me to be the "Corporate Oracle",or, indeed, "The Devil's Advocate"
(See tvtropes.org for funny exposition) for a moment and tell you it
can't be done and/or it has no future.
(You saw the maximum MFC version Stingray would work with and the message
they built in, asking you to ask for an update to pay more for. I've made
sure you've seen the insane inline assembler debugging embedded. Also, the
warning that this code wont survive a 64bit transition!)
No matter how you approach it, this code is gonna get obsolete soon.
I'm sorry. Noone likes the messenger carrying bad news, but here I am with
the full depeche ready to hit the fan..
I realise you pay a fortune for this program, but why?, If outlook is more
or less built into W$ why don't you use this or a combination of other
programs tailored to meet the platform in question. Be it M$ or MAC or
POSIX.
Have the users of Eudora/Hermes gotten so stuck in their ways that they
can't transition to a "new way of doing things".
What I mean is that, as Mr. Matavka has seen, mail functionality is built
into M$ examples. A full outlook clone with proper language support is
build into the, so called, "Simple MAPI".
Using OLE to transfer data to an forth this client program may be
possible, but it's a lot of work. Realistically it would be more feasable
to hide the server program Hermes/Eudora and let M$ handle it all.
I realise you're not all using the client for "personal" purposes, an as
such, the free use clauses won't apply. Bt there must be a way aroun that
using several tools.
Has anyone been down this road?
Cordially (and in the hope of not getting slaughtered outright :) ),
Søren.
PS: I'm got gonna hit Local TV soon and those of you with half a brain,
and a somewhere decent command of Danish (This will be my rescue. :) ) will
realise who's "messing around" with your code and/or seeing elephants.
Well, I certainly see the elephant in the room now. I somehow managed to unsub myself from the discussion, which meant that I was no longer getting eMail notifications as I used to. To top it off, I spent €300 on a used BlackBerry Key2, which arrived in unusable and irreparable condition (mainboard issues), contrary to the seller's description. I am just now attempting to get a refund, which will be next to impossible judging by the seller's name and address (first name is Chaim, address is in Brooklyn NY, "being miserable and treating other people like dirt is every New Yorker's God-given right."). That's the problem with eBay—you never can tell if you're buying from the wrong kind of person.
First of all, anything that includes the string "OT501" is Stingray and may (note, may, not must) be filed in /dev/null. OT501 stands for Objective Toolkit 5.01, which was what Stingray Studio was called before it was bought out by QuovadX. Now, Mr McLean, you have access to the Stingray libraries (in that big exe file) and I'm expecting you to exercise your best judgement, subject to the caveat that anything that depends on Stingray will not be publicly distributed, especially not with the library. There's an important distinction here: the former is just good practice, while the latter is copyright infringement.
Second—and I do believe I've made reference to this before—Mr Thygesen, I think you're completely right, as long as we're talking about the same thing. You say "this code is gonna get obsolete soon", I'm going to assume that by "this code" you mean the interface, frontend, or whatever you wish to call eudora.exe. If John Noerenberg, Jeff Beckley and Jeff Gehlhaar (the creators of Eudora for Windows) were on this project, they'd probably decide to write an entirely new frontend in pure MFC, taking specific care to keep the general look and feel. I am specifically instructing you to do precisely this, if and only if the task of making the original eudora.exe project compile is insurmountable.
Third, in regards to workflow and priorities: let's try to compile the projects one by one. Whatever compiles without error, we prioritise. If there are minor glitches or bugs, we fix those. QCUtils works, so we mark it as "done" in the header of the .c file, merge it, and go on to the next thing. QCSSL works too (subject to continued maintenance by Mr McLean). Then we tackle the major jobs.
Fourth, the debugging code posted by Mr Thygesen, accompanied by his comments, is very, very worrying. I have seen software that is so overgrown with workarounds and patches that you couldn't see the original source underneath. At that point, I'd like to put the thing out of its misery. I don't exactly want to do that right now, but combined with point number two, it might make sense. Such a decision is not to be taken lightly, but I trust you two to work it out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am very much in sync with you, Søren, concerning how much I can contribute to this project. As a Eudora user of many years, I have passion and zest for it. As an experienced email developer, I have masterful expertise in many large areas of the code, although not all. However I have a business to run and a very busy life aside from that which severely limits how much time I can give to Hermes. So even as a well matched professional team we fall far short of what a similar duo could achieve in a full-time, paid situation.
In the last part of your message you seem to be suggesting that we might take a new and different approach to creating Hermes but, sorry, I am unable to understand your idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm gonna raise a level or two above my "pay-grade" and talk about the
elephant in the room. With which I mean the possibility that making
Eudora/Hermes compile and run is impossible, or indeed infeasable, for
(possibly?) two programmers who doesn't even devote a job-like attention to
the task but jump in and out at their whims and other social contracts they
might have. (I'm talking for myself mostly, but I'm sure Mr. Maclean can
nod in recognision, if not agreement.)
A proper company would have a guy who foretells the future. I forget what
his job-description is, but it could, likely, be "Corporate Oracle".
Allow me to be the "Corporate Oracle",or, indeed, "The Devil's Advocate"
(See tvtropes.org for funny exposition) for a moment and tell you it can't
be done and/or it has no future.
(You saw the maximum MFC version Stingray would work with and the message
they built in, asking you to ask for an update to pay more for. I've made
sure you've seen the insane inline assembler debugging embedded. Also, the
warning that this code wont survive a 64bit transition!)
No matter how you approach it, this code is gonna get obsolete soon.
I'm sorry. Noone likes the messenger carrying bad news, but here I am with
the full depeche ready to hit the fan..
I realise you pay a fortune for this program, but why?, If outlook is more
or less built into W$ why don't you use this or a combination of other
programs tailored to meet the platform in question. Be it M$ or MAC or
POSIX.
Have the users of Eudora/Hermes gotten so stuck in their ways that they
can't transition to a "new way of doing things".
What I mean is that, as Mr. Matavka has seen, mail functionality is built
into M$ examples. A full outlook clone with proper language support is
build into the, so called, "Simple MAPI".
Using OLE to transfer data to an forth this client program may be possible,
but it's a lot of work. Realistically it would be more feasable to hide the
server program Hermes/Eudora and let M$ handle it all.
I realise you're not all using the client for "personal" purposes, an as
such, the free use clauses won't apply. Bt there must be a way aroun that
using several tools.
Has anyone been down this road?
Cordially (and in the hope of not getting slaughtered outright :) ),
Søren.
PS: I'm got gonna hit Local TV soon and those of you with half a brain, and
a somewhere decent command of Danish (This will be my rescue. :) ) will
realise who's "messing around" with your code and/or seeing elephants.
Arrgh, who don't, ignore the grammar please.
Regards,
On Mon, Nov 26, 2018 at 8:18 PM sbrothy@gmail.com wrote:
Well, I certainly see the elephant in the room now. I somehow managed to unsub myself from the discussion, which meant that I was no longer getting eMail notifications as I used to. To top it off, I spent €300 on a used BlackBerry Key2, which arrived in unusable and irreparable condition (mainboard issues), contrary to the seller's description. I am just now attempting to get a refund, which will be next to impossible judging by the seller's name and address (first name is Chaim, address is in Brooklyn NY, "being miserable and treating other people like dirt is every New Yorker's God-given right."). That's the problem with eBay—you never can tell if you're buying from the wrong kind of person.
First of all, anything that includes the string "OT501" is Stingray and may (note, may, not must) be filed in /dev/null. OT501 stands for Objective Toolkit 5.01, which was what Stingray Studio was called before it was bought out by QuovadX. Now, Mr McLean, you have access to the Stingray libraries (in that big exe file) and I'm expecting you to exercise your best judgement, subject to the caveat that anything that depends on Stingray will not be publicly distributed, especially not with the library. There's an important distinction here: the former is just good practice, while the latter is copyright infringement.
Second—and I do believe I've made reference to this before—Mr Thygesen, I think you're completely right, as long as we're talking about the same thing. You say "this code is gonna get obsolete soon", I'm going to assume that by "this code" you mean the interface, frontend, or whatever you wish to call eudora.exe. If John Noerenberg, Jeff Beckley and Jeff Gehlhaar (the creators of Eudora for Windows) were on this project, they'd probably decide to write an entirely new frontend in pure MFC, taking specific care to keep the general look and feel. I am specifically instructing you to do precisely this, if and only if the task of making the original eudora.exe project compile is insurmountable.
Third, in regards to workflow and priorities: let's try to compile the projects one by one. Whatever compiles without error, we prioritise. If there are minor glitches or bugs, we fix those. QCUtils works, so we mark it as "done" in the header of the .c file, merge it, and go on to the next thing. QCSSL works too (subject to continued maintenance by Mr McLean). Then we tackle the major jobs.
Fourth, the debugging code posted by Mr Thygesen, accompanied by his comments, is very, very worrying. I have seen software that is so overgrown with workarounds and patches that you couldn't see the original source underneath. At that point, I'd like to put the thing out of its misery. I don't exactly want to do that right now, but combined with point number two, it might make sense. Such a decision is not to be taken lightly, but I trust you two to work it out.
I am very much in sync with you, Søren, concerning how much I can contribute to this project. As a Eudora user of many years, I have passion and zest for it. As an experienced email developer, I have masterful expertise in many large areas of the code, although not all. However I have a business to run and a very busy life aside from that which severely limits how much time I can give to Hermes. So even as a well matched professional team we fall far short of what a similar duo could achieve in a full-time, paid situation.
In the last part of your message you seem to be suggesting that we might take a new and different approach to creating Hermes but, sorry, I am unable to understand your idea.