OK, I thought the error was the SDK version but it's really the MFC version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
*hermesmail-code\Eudora71\GSSupport*
I know inline assembler was once a good idea but it's not anymore. Chipsets
are too diverse or something like that, I'm not omni-something. It just
worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
*hermesmail-code\Eudora71\GSSupport*
I know inline assembler was once a good idea but it's not anymore.
Chipsets are too diverse or something like that, I'm not omni-something. It
just worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
I'm not paranoid but I might become it if I read more comments like these:
[...] // We override the Bugslayer definitions of ASSERT and VERIFY to instead // go through our wrapper macros, because the Eudora code relies on the // do-while(0) mechanism for wrapping. The Eudora code has cases like
this: // if (error) // ASSERT(0); // else // DoSomething(); // With the Bugslayer technique of just adding a level of scope code // like this will result in an error: // error C2181: illegal else without matching if // // With the do-while(0) mechanism code like above works. Long term // I'd like to see us rewrite cases like above, but for now we'll // continue to support it.
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Regards.
On Sat, Nov 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
Well, I've got good news and I've got bad news.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
hermesmail-code\Eudora71\GSSupport
I know inline assembler was once a good idea but it's not anymore.
Chipsets are too diverse or something like that, I'm not omni-something. It
just worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
Regards.
On Sat, Nov 24, 2018 at 5:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Regards.
I'm not paranoid but I might become it if I read more comments like these:
[...] // We override the Bugslayer definitions of ASSERT and VERIFY to instead // go through our wrapper macros, because the Eudora code relies on the // do-while(0) mechanism for wrapping. The Eudora code has cases like
this: // if (error) // ASSERT(0); // else // DoSomething(); // With the Bugslayer technique of just adding a level of scope code // like this will result in an error: // error C2181: illegal else without matching if // // With the do-while(0) mechanism code like above works. Long term // I'd like to see us rewrite cases like above, but for now we'll // continue to support it.
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Regards.
On Sat, Nov 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
Well, I've got good news and I've got bad news.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
hermesmail-code\Eudora71\GSSupport
I know inline assembler was once a good idea but it's not anymore.
Chipsets are too diverse or something like that, I'm not omni-something.
It
just worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
Regards.
On Sat, Nov 24, 2018 at 5:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Regards.
Nah, I think many of my problems are due to the fact that I deleted parts
of the SDK to clean up. When I have the entire SDK installed again I'll be
back on track.
Still, some of the things I find do worry me from a "make it work" point of
view.
They override the language defined do{}while() construct?
That's a little scary. And all for debug purposes? I'm sure Pete would be
able to calm me down but it does worry me a little.
Regards.
On Sat, Nov 24, 2018 at 6:47 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Regards.
On Sat, Nov 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
Well, I've got good news and I've got bad news.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
hermesmail-code\Eudora71\GSSupport
I know inline assembler was once a good idea but it's not anymore.
Chipsets are too diverse or something like that, I'm not omni-something.
It
just worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
Regards.
On Sat, Nov 24, 2018 at 5:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Regards.
I'm continuing this discussion, partly in the hope that Pete will
resurface, partly in the hope of educating myself and keep my train of
thought going, and partly to show whomever it may concern, that not all
have lost interest in seeing this project through to whatever conclusion
may be at the end of the proverbial rainbow.
A lot of errors are removable by proper configuration. SDK version, MFC
version; the proper Visual Studio setup basically. I've experienced a
falling number of errors just by removing newer versions of the SDK from my
Windows program list. That kind of thing. It should really be in a manual
somewhere - and probably is, I just didn't read it :) - but if not it
should be possible to "Monte-Carlo"-simulate our way to the proper config.
I mean from several thousand errors to less than thousand by not changing a
letter in the code. Just by toying with the configuration. That has to be a
good sign doesn't it?
Nah, I think many of my problems are due to the fact that I deleted parts
of the SDK to clean up. When I have the entire SDK installed again I'll be
back on track.
Still, some of the things I find do worry me from a "make it work" point of
view.
Regards.
On Sat, Nov 24, 2018 at 8:19 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I mean why did they get into this level of debugging? That must have to do
with unintended consequences or side effects of bad code....
Regards.
On Sat, Nov 24, 2018 at 8:16 PM sbrothy@gmail.com wrote:
I'm not paranoid but I might become it if I read more comments like these:
[...] // We override the Bugslayer definitions of ASSERT and VERIFY to instead // go through our wrapper macros, because the Eudora code relies on the
// do-while(0) mechanism for wrapping. The Eudora code has cases like
this:*
// if (error)*
// ASSERT(0);*
// else*
// DoSomething();*
// With the Bugslayer technique of just adding a level of scope code*
// like this will result in an error:*
// error C2181: illegal else without matching if*
//*
// With the do-while(0) mechanism code like above works. Long term*
// I'd like to see us rewrite cases like above, but for now we'll*
-
// continue to support it.*
-
define QCVERIFY_WRAPPERMACRO(expr)
- do {
- NEWVERIFY(expr); *
-
} while (0) - define QCASSERT_WRAPPERMACRO(expr)
- do { - NEWASSERT(expr);
-
They override the language defined do{}while() construct?
That's a little scary. And all for debug purposes? I'm sure Pete would be
able to calm me down but it does worry me a little.
Regards.
On Sat, Nov 24, 2018 at 6:47 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Regards.
On Sat, Nov 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
Well, I've got good news and I've got bad news.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
hermesmail-code\Eudora71\GSSupport
I know inline assembler was once a good idea but it's not anymore.
Chipsets are too diverse or something like that, I'm not omni-something.
It
just worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
Regards.
On Sat, Nov 24, 2018 at 5:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
OK, I thought the error was the SDK version but it's really the MFC
version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Regards.
I need to answer this rather tentatively since I have no actual experience in working with configurations of the kind you are describing. I do agree that eliminating compilation errors by configuring the project to use older versions of the SDK and MFC must be a good thing. And I congratulate you on experimenting with this approach and achieving such encouraging results. But I am concerned that, in some cases, it may be a good thing only as a first step. Since most older versions of the SDK are very forward-compatible, it should be safe to build to an older version -- indeed, this is exactly why programs like Eudora built 20+ years ago still run perfectly well on current versions of Windows. However at some point in future we may find compelling reason to use features that are specific to newer SDKs in which case we will be forced to do something else to avoid all those errors we are eliminating now. I would be tempted to use the observation that certain errors are eliminated by reconfiguring the SDK version to better understand those errors and to then eliminate them by other means. But this is just me; I do not mean to push you to do the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, that's exactly the right idea, Mr Maclean. While we can reconfigure to a 2005 setup, such a thing is undesirable in my eyes, because my goal for this is for it to compile in a modern environment and run on a modern computer. Now, that's a "warning", not an "error", in IDE-speak.
I'd like to see precisely what you suggest: eliminate the dependencies on older software through a process of abductive reasoning or otherwise. Realistically, though, I'd settle for compilation with older software (excluding dependencies on OT501), and failing that, a whole new front end, but with the design of the old front end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I thought the error was the SDK version but it's really the MFC version
the Stingray Toolkit complains about. That's what I get for using the same
workstation for Eudora and fantasy-Hermes.
I'll be all over it in a minute. Even though it's only a warning from the
Stingray developers it could be a serious one. I suspect, though, it's
only there to try to force you to contact them to buy a newer version.
We'll treat it seriously until proven wrong though.
I'll download the project again even though I know it's overkill and noone
changed a thing anyway.
Regards.
Well, I've got good news and I've got bad news.
Immediately after download, and adding "the ineffable header", it seems
we're down to 644 errors and 48 warnings.
We've got a some security checking code overriding some of Microsoft's own
buffer overflow checking in the directory:
*hermesmail-code\Eudora71\GSSupport*
I know inline assembler was once a good idea but it's not anymore. Chipsets
are too diverse or something like that, I'm not omni-something. It just
worries me.
Finding stuff like inline assembler and comments like:
// This api won't be ported to Win64 - Fix your code. [DbgHelp.h]
Fix my code?
WTF?
Why would anyone need this much debug detail? Assembler debug detail? No
unit debugging perhaps?. It's ugly that's for sure.
Then again, I'm just complaining because my original error dissapeared!
Where id it go? My whole world just crumbled into despair.
Regards.
On Sat, Nov 24, 2018 at 5:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
The preferred solution is making the individual projects in the solution
work. One by one. Some do compile. QCUtils for example. (albeit with some
severe warnings).
Regards.
On Sat, Nov 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
I'm not paranoid but I might become it if I read more comments like these:
[...]
// We override the Bugslayer definitions of ASSERT and VERIFY to instead
// go through our wrapper macros, because the Eudora code relies on the
// do-while(0) mechanism for wrapping. The Eudora code has cases like
this:
// if (error)
// ASSERT(0);
// else
// DoSomething();
// With the Bugslayer technique of just adding a level of scope code
// like this will result in an error:
// error C2181: illegal else without matching if
//
// With the do-while(0) mechanism code like above works. Long term
// I'd like to see us rewrite cases like above, but for now we'll
// continue to support it.
define QCVERIFY_WRAPPERMACRO(expr) *
} while (0)*
define QCASSERT_WRAPPERMACRO(expr) *
} while (0)*
define VERIFYLOG(expr) QCVERIFY_WRAPPERMACRO(expr)*
define EXPRLOG(expr) QCVERIFY_WRAPPERMACRO(expr)*
ifdef VERIFY*
undef VERIFY*
endif*
[...]
They override the language defined do{}while() construct?
That's a little scary. And all for debug purposes? I'm sure Pete would be
able to calm me down but it does worry me a little.
Regards.
On Sat, Nov 24, 2018 at 6:47 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I mean why did they get into this level of debugging? That must have to do
with unintended consequences or side effects of bad code....
Regards.
On Sat, Nov 24, 2018 at 8:16 PM sbrothy@gmail.com wrote:
Nah, I think many of my problems are due to the fact that I deleted parts
of the SDK to clean up. When I have the entire SDK installed again I'll be
back on track.
Still, some of the things I find do worry me from a "make it work" point of
view.
Regards.
On Sat, Nov 24, 2018 at 8:19 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I'm continuing this discussion, partly in the hope that Pete will
resurface, partly in the hope of educating myself and keep my train of
thought going, and partly to show whomever it may concern, that not all
have lost interest in seeing this project through to whatever conclusion
may be at the end of the proverbial rainbow.
A lot of errors are removable by proper configuration. SDK version, MFC
version; the proper Visual Studio setup basically. I've experienced a
falling number of errors just by removing newer versions of the SDK from my
Windows program list. That kind of thing. It should really be in a manual
somewhere - and probably is, I just didn't read it :) - but if not it
should be possible to "Monte-Carlo"-simulate our way to the proper config.
I mean from several thousand errors to less than thousand by not changing a
letter in the code. Just by toying with the configuration. That has to be a
good sign doesn't it?
Regards.
On Sat, Nov 24, 2018 at 8:32 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I need to answer this rather tentatively since I have no actual experience in working with configurations of the kind you are describing. I do agree that eliminating compilation errors by configuring the project to use older versions of the SDK and MFC must be a good thing. And I congratulate you on experimenting with this approach and achieving such encouraging results. But I am concerned that, in some cases, it may be a good thing only as a first step. Since most older versions of the SDK are very forward-compatible, it should be safe to build to an older version -- indeed, this is exactly why programs like Eudora built 20+ years ago still run perfectly well on current versions of Windows. However at some point in future we may find compelling reason to use features that are specific to newer SDKs in which case we will be forced to do something else to avoid all those errors we are eliminating now. I would be tempted to use the observation that certain errors are eliminated by reconfiguring the SDK version to better understand those errors and to then eliminate them by other means. But this is just me; I do not mean to push you to do the same.
No, that's exactly the right idea, Mr Maclean. While we can reconfigure to a 2005 setup, such a thing is undesirable in my eyes, because my goal for this is for it to compile in a modern environment and run on a modern computer. Now, that's a "warning", not an "error", in IDE-speak.
I'd like to see precisely what you suggest: eliminate the dependencies on older software through a process of abductive reasoning or otherwise. Realistically, though, I'd settle for compilation with older software (excluding dependencies on OT501), and failing that, a whole new front end, but with the design of the old front end.