I have been putting some serious thought into how we'll introduce cross-platform support into HERMES. It would seem that MFC provides a nice, easy way to build the GUI with not even all that much coding required, and it also supports dockable windows. The downside to this approach is that MFC is strictly Windows-compatible.
On the other hand, WxWindows is cross-platform, but it has its downsides, chief among which is its unsexiness. We'd have to hand-code some sort of dockable capability, which would not come easy at all, and that's just the beginning of our problems.
If we had a functional Mac-compatible version of Eudora to work from, we could maybe maintain parallel codebases as QUALCOMM had done, but there are problems with that approach as well. First of all, we don't have a functional Mac version: it lacks all the resource forks, and it's a Carbon app, meaning it's x86-only. Apple will remove x86 support in the next version of OS X, and Carbon is unstable enough as-is (it'd also need quite a lot of work to make Unicode-compatible). Add to that the problem that it's in C rather than C++.
The only solution I can see is that we write an MFC version first. Once that's done, and we have our first gold release out the door, we'll try to re-write what we can in WxWidgets; that'll form the cross-platform core. What can't be done in WxWidgets will be done in MFC on Windows, in Cocoa on OS X, in GTK on Linux, etc.
Another issue that's come up is processor architecture. By and large, the industry has standardised on x64 for everything from personal computers to supercomputer farms (the only exceptions are IBM mainframes and mobile computing). This means that we could theoretically drop x86 support, but I don't exactly want to do this unless necessary.
I think what we'll do is create an x64 branch of the source tree, just to speed things up. A legacy x86 release is only the second or third priority, but make no mistake, it is a priority. Still, if we can't for some reason or another get x86 to work, we'll have a release that does work---which means we can pat ourselves on the back that we haven't spent the last six months doing the software-development equivalent of masturbation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The dockable functionality is there alright. I seem to remember some
auxillary class making it possible. AUX is even in it's name. So yes, it
possible, as you say. The frustrating part is that MFC and WxWidgets looks
so alike but still are so different. With WxWidgets, not much is
guaranteed. The seemless Windows interoperability is gone. No Inherent OLE
automation (I'm a big fan of embedded HTML) and I'm sure the users are as
well. Even if they don't know what makes HTML pages magically appear in
their messages.
This is just to let you know I read your message. I'm still thinking....
I have been putting some serious thought into how we'll introduce
cross-platform support into HERMES. It would seem that MFC provides a nice,
easy way to build the GUI with not even all that much coding required, and
it also supports dockable windows. The downside to this approach is that
MFC is strictly Windows-compatible.
On the other hand, WxWindows is cross-platform, but it has its downsides,
chief among which is its unsexiness. We'd have to hand-code some sort of
dockable capability, which would not come easy at all, and that's just the
beginning of our problems.
If we had a functional Mac-compatible version of Eudora to work from, we
could maybe maintain parallel codebases as QUALCOMM had done, but there
are problems with that approach as well. First of all, we don't have a
functional Mac version: it lacks all the resource forks, and it's a Carbon
app, meaning it's x86-only. Apple will remove x86 support in the next
version of OS X, and Carbon is unstable enough as-is (it'd also need quite
a lot of work to make Unicode-compatible). Add to that the problem that
it's in C rather than C++.
The only solution I can see is that we write an MFC version first. Once
that's done, and we have our first gold release out the door, we'll try to
re-write what we can in WxWidgets; that'll form the cross-platform core.
What can't be done in WxWidgets will be done in MFC on Windows, in Cocoa on
OS X, in GTK on Linux, etc.
Another issue that's come up is processor architecture. By and large, the
industry has standardised on x64 for everything from personal computers to
supercomputer farms (the only exceptions are IBM mainframes and mobile
computing). This means that we could theoretically drop x86 support, but I
don't exactly want to do this unless necessary.
I think what we'll do is create an x64 branch of the source tree, just to
speed things up. A legacy x86 release is only the second or third priority,
but make no mistake, it is a priority. Still, if we can't for some
reason or another get x86 to work, we'll have a release that does
work---which means we can pat ourselves on the back that we haven't spent
the last six months doing the software-development equivalent of
masturbation.
I must jump in and say that I think creating a separate branch for an x64 Hermes would be a big mistake. At least in the Windows world, in most cases, there need be very little difference between 32-bit and 64-bit code. I was telling Soren privately earlier today that I have several programs that I build in both 32- and 64-bit versions from a single code base in each case. Taking one example, a program with 135,000 lines of C++ code in 193 modules has only 26 sections that are conditionally compiled in different ways for 32 versus 64 and many of those contain only single-line alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour of creating a 64-bit Hermes. But only after we have a clean and completed 32-bit version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must jump in and say that I think creating a separate branch for an x64
Hermes would be a big mistake. At least in the Windows world, in most
cases, there need be very little difference between 32-bit and 64-bit code.
I was telling Soren privately earlier today that I have several programs
that I build in both 32- and 64-bit versions from a single code base in
each case. Taking one example, a program with 135,000 lines of C++ code in
193 modules has only 26 sections that are conditionally compiled in
different ways for 32 versus 64 and many of those contain only single-line
alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour
of creating a 64-bit Hermes. But only after we have a clean and completed
32-bit version.
My reading of Mr Thygesen's eMail is that he judges the 64-bit version to
be easier to write/compile than the 32-bit. That is the only reason I
suggested branching off.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
I must jump in and say that I think creating a separate branch for an x64
Hermes would be a big mistake. At least in the Windows world, in most
cases, there need be very little difference between 32-bit and 64-bit code.
I was telling Soren privately earlier today that I have several programs
that I build in both 32- and 64-bit versions from a single code base in
each case. Taking one example, a program with 135,000 lines of C++ code in
193 modules has only 26 sections that are conditionally compiled in
different ways for 32 versus 64 and many of those contain only single-line
alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour
of creating a 64-bit Hermes. But only after we have a clean and completed
32-bit version.
My reading of Mr Thygesen's eMail is that he judges the 64-bit version to
be easier to write/compile than the 32-bit. That is the only reason I
suggested branching off.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
I must jump in and say that I think creating a separate branch for an x64
Hermes would be a big mistake. At least in the Windows world, in most
cases, there need be very little difference between 32-bit and 64-bit
code.
I was telling Soren privately earlier today that I have several programs
that I build in both 32- and 64-bit versions from a single code base in
each case. Taking one example, a program with 135,000 lines of C++ code in
193 modules has only 26 sections that are conditionally compiled in
different ways for 32 versus 64 and many of those contain only single-line
alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour
of creating a 64-bit Hermes. But only after we have a clean and completed
32-bit version.
My reading of Mr Thygesen's eMail is that he judges the 64-bit version to
be easier to write/compile than the 32-bit. That is the only reason I
suggested branching off.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
I have been putting some serious thought into how we'll introduce cross-platform support into HERMES. It would seem that MFC provides a nice, easy way to build the GUI with not even all that much coding required, and it also supports dockable windows. The downside to this approach is that MFC is strictly Windows-compatible.
On the other hand, WxWindows is cross-platform, but it has its downsides, chief among which is its unsexiness. We'd have to hand-code some sort of dockable capability, which would not come easy at all, and that's just the beginning of our problems.
If we had a functional Mac-compatible version of Eudora to work from, we could maybe maintain parallel codebases as QUALCOMM had done, but there are problems with that approach as well. First of all, we don't have a functional Mac version: it lacks all the resource forks, and it's a Carbon app, meaning it's x86-only. Apple will remove x86 support in the next version of OS X, and Carbon is unstable enough as-is (it'd also need quite a lot of work to make Unicode-compatible). Add to that the problem that it's in C rather than C++.
The only solution I can see is that we write an MFC version first. Once that's done, and we have our first gold release out the door, we'll try to re-write what we can in WxWidgets; that'll form the cross-platform core. What can't be done in WxWidgets will be done in MFC on Windows, in Cocoa on OS X, in GTK on Linux, etc.
Another issue that's come up is processor architecture. By and large, the industry has standardised on x64 for everything from personal computers to supercomputer farms (the only exceptions are IBM mainframes and mobile computing). This means that we could theoretically drop x86 support, but I don't exactly want to do this unless necessary.
I think what we'll do is create an x64 branch of the source tree, just to speed things up. A legacy x86 release is only the second or third priority, but make no mistake, it is a priority. Still, if we can't for some reason or another get x86 to work, we'll have a release that does work---which means we can pat ourselves on the back that we haven't spent the last six months doing the software-development equivalent of masturbation.
The dockable functionality is there alright. I seem to remember some
auxillary class making it possible. AUX is even in it's name. So yes, it
possible, as you say. The frustrating part is that MFC and WxWidgets looks
so alike but still are so different. With WxWidgets, not much is
guaranteed. The seemless Windows interoperability is gone. No Inherent OLE
automation (I'm a big fan of embedded HTML) and I'm sure the users are as
well. Even if they don't know what makes HTML pages magically appear in
their messages.
This is just to let you know I read your message. I'm still thinking....
Regards.
On Mon, Oct 29, 2018 at 6:41 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
I must jump in and say that I think creating a separate branch for an x64 Hermes would be a big mistake. At least in the Windows world, in most cases, there need be very little difference between 32-bit and 64-bit code. I was telling Soren privately earlier today that I have several programs that I build in both 32- and 64-bit versions from a single code base in each case. Taking one example, a program with 135,000 lines of C++ code in 193 modules has only 26 sections that are conditionally compiled in different ways for 32 versus 64 and many of those contain only single-line alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour of creating a 64-bit Hermes. But only after we have a clean and completed 32-bit version.
On Mon, 29 Oct 2018 at 17:45, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
"If we had a functional Mac-compatible version of Eudora to work from [...]"
If we have the MAC source code, and it compiles and works, why dont't we
use this to rewrite the Windows version?
Regards.
On Mon, Oct 29, 2018 at 10:48 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
(AFK)
.. aaand, that's what you just explained. Sorry. Nevermind.
Regards
On Tuesday, October 30, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen