I know the Linux subject has been raised before, but since DMC prides itself on speed and compact executables, I felt it appropriate to post some comments from another developer regarding the GNU C++ tools on Linux.  He is porting code from MSVC6 to GCC.

So it appears that DMC could really help a lot of Linux folks if it were ever ported.

Still thanks for such a wonderful compiler for Windows.  I am really gratified by the progress being made on namespaces and templates.

Mark

================================================

Another issue, is the complete and utter sluggishness of g++. Holy CRAP!! those of you who know me have heard me get on my rant as to why is VC6 so friggin slow. Damn, VC6 is a friggin sprinter compared to the turtle that is g++. Compiling ... takes around 40 minutes. It takes 15 on VC6. And the  output for g++ is also nothing short of a incredible! The .so with the -ggdb flag turned on (this is supposed to  put in gdb compliant debug information), weighs in at a whopping 36 MB!!!  Thats right, not 3.6 MB, but 36MB, I had to double check the size myself  before I beleived it. And running "strip" on it reduces it to a "mere" 7MB in size.  The comparable data for VC6 (the applicationKit_d.dll, map, idb, and pdb) weighs in at 17MB, and the size of the image itself  is 1.9. Sigh....

If I can convince more of the djgpp and cygnus g++-on-windows people to switch to DMC++, then a good case can be made for the viability of a linux version.

DMC++ is small and fast because its heritage is as a DOS compiler where speed & size were incredibly important.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:av27oh$vde$1@digitaldaemon.com...
> I know the Linux subject has been raised before, but since DMC prides
itself on
> speed and compact executables, I felt it appropriate to post some comments
from
> another developer regarding the GNU C++ tools on Linux.  He is porting
code from
> MSVC6 to GCC.
>
> So it appears that DMC could really help a lot of Linux folks if it were
ever
> ported.
>
> Still thanks for such a wonderful compiler for Windows.  I am really
gratified
> by the progress being made on namespaces and templates.
>
> Mark
>
> ================================================
>
> Another issue, is the complete and utter sluggishness of g++. Holy CRAP!!
those
> of you who know me have heard me get on my rant as to why is VC6 so
friggin
> slow. Damn, VC6 is a friggin sprinter compared to the turtle that is g++. Compiling ... takes around 40 minutes. It takes 15 on VC6. And the  output
for
> g++ is also nothing short of a incredible! The .so with the -ggdb flag
turned on
> (this is supposed to  put in gdb compliant debug information), weighs in
at a
> whopping 36 MB!!!  Thats right, not 3.6 MB, but 36MB, I had to double
check the
> size myself  before I beleived it. And running "strip" on it reduces it to
a
> "mere" 7MB in size.  The comparable data for VC6 (the
applicationKit_d.dll,
> map, idb, and pdb) weighs in at 17MB, and the size of the image itself  is
1.9.
> Sigh....
>
>

You would be asking those people to re-write all their make scripts and such. Not likely.  They're using Cygwin for a reason:  it lessens code maintenance tasks.  It provides a standard Unix environment on Windows.

So you would be asking them to drop their beloved Unix environment.  The only way around that would be a version of DMC which uses Cygwin headers and the POSIX-compliant Cygwin.DLL.  That's effectively a Linux port anyway; might as well do the real thing!

What migration exists today is mostly from Windows to Linux, not the other way. So targeting Linux/GNU folks on Windows seems a non-starter.

The people to target are Windows folks migrating into cross-platform Windows/Linux development -- much as Borland did with Delphi-cum-Kylix.

Right now, with G++ supported on both platforms, it's a rather obvious choice for cross-platform work (flaws notwithstanding).  All DMC need do is offer an alternative for cross-platform work.

I venture that 80% or more of the cross-platform groups in existence are using MSVC6 for Windows support and G++ for Linux support.  This includes OpenOffice, complete with their horrific build scripts.  The chances of those scripts being rewritten for another Windows compiler are nil.

On the other hand, if they had a true cross-platform free compiler, they might consider it.  Why they didn't use G++ in the first place is a mystery to me.  It may revolve around various SDK requirements on the Windows side (they use certain Microsoft SDKs and even require the Microsoft assembler for certain things).

Note too that Mac OS X is just a tweaked BSD Unix, so DMC for Linux would work on Macs as well.  That's two platforms for the price of one port.

Mark


Walter says...
>
>If I can convince more of the djgpp and cygnus g++-on-windows people to switch to DMC++, then a good case can be made for the viability of a linux version.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:av2in5$15p3$1@digitaldaemon.com...
> You would be asking those people to re-write all their make scripts and
such.
> Not likely.  They're using Cygwin for a reason:  it lessens code
maintenance
> tasks.  It provides a standard Unix environment on Windows.

While I'm sure those are a significant chuck of Cygwin users, I don't see that issue come up as the reason - I've never seen them say they feel trapped into using Cygwin because of the scripts.

> So you would be asking them to drop their beloved Unix environment.  The
only
> way around that would be a version of DMC which uses Cygwin headers and
the
> POSIX-compliant Cygwin.DLL.  That's effectively a Linux port anyway; might
as
> well do the real thing!

To me, that's Cygwin's greatest drawback. If you're going to write a professional quality product and ship it on Windows, it ought to be a Windows app from the ground up. I've found I've been able to tell a Cygwin built app just by running it. It has a linuxee feel to the user interface (even the command line ones), the file handling isn't quite compatible with windows file systems, the command line string handling isn't right, it doesn't handle windowy things like Ctrl-Break right, etc.

> Right now, with G++ supported on both platforms, it's a rather obvious
choice
> for cross-platform work (flaws notwithstanding).  All DMC need do is offer
an
> alternative for cross-platform work.

I've written professional products that work on both linux and Windows. I've never felt a need to use Cygwin to make that happen on the Windows side. But I can see the appeal of using the same compiler on both platforms.


> I venture that 80% or more of the cross-platform groups in existence are
using
> MSVC6 for Windows support and G++ for Linux support.  This includes
OpenOffice,
> complete with their horrific build scripts.  The chances of those scripts
being
> rewritten for another Windows compiler are nil.

<g> Sometimes I think I'm the only one who shuns complex build scripts. I've seen some that used bizarre combinations of Perl, bash, C, awk, what-have-you. Just to build the program, you had to find/load tons of other software (and of course the scripts were sensitive to particular versions of all that software, arggh). When I finally figured out what all those things were doing, it was easy to replace them with a straightforward makefile. Now, granted, DMC++'s runtime library has some execrable build scripts for the RTL, but I've been rewriting them as I incidentally need to do other work on them.

Don't get me wrong, I'd love to make a full-up linux version of DMC++. The trouble is I am completely maxed out supporting 4 professional level compilers. I do the tech support too (and I'm very grateful when others here step in and help out!) Ask other compiler vendors how many engineers they assign to just one product <g>.

Doing a linux port is not easy. It would have to be binary compatible with gcc's output, and would have to have much of the extensions added that gcc has.

>While I'm sure those are a significant chuck of Cygwin users, I don't see that issue come up as the reason - I've never seen them say they feel trapped into using Cygwin because of the scripts.

I don't see why else they would be building their code under Cygwin except the cross-platform aspect and the scripts.  Otherwise they'd just support two platforms natively, like OpenOffice -- which also uses Cygwin anyway, for the scripts!

>To me, that's Cygwin's greatest drawback. If you're going to write a professional quality product and ship it on Windows, it ought to be a Windows app from the ground up.

Right, and DMC already does that.  The Linux is what's missing.

>I've written professional products that work on both linux and Windows. I've never felt a need to use Cygwin to make that happen on the Windows side. But I can see the appeal of using the same compiler on both platforms.

Yes it's a no-brainer really.

>Don't get me wrong, I'd love to make a full-up linux version of DMC++. The trouble is I am completely maxed out supporting 4 professional level compilers. I do the tech support too (and I'm very grateful when others here step in and help out!) Ask other compiler vendors how many engineers they assign to just one product <g>.

As has been mentioned before, there are dozens of people ready willing and able to help under nondisclosure terms.  So far you've nixed that idea every time it has been floated.  And there is never any talk of just open-sourcing all this stuff which would be ideal for everyone involved.

>Doing a linux port is not easy. It would have to be binary compatible with gcc's output, and would have to have much of the extensions added that gcc has.

You'd be amazed at what would happen if DMC were open-sourced!  I know, I know, licensing issues....well, I don't see what interest Symantec has in keeping all this under wraps at this late date.

Mark

On Thu, 2 Jan 2003 23:41:25 +0000 (UTC), Mark Evans wrote:
> So you would be asking them to drop their beloved Unix environment.  The only way around that would be a version of DMC which uses Cygwin headers and the POSIX-compliant Cygwin.DLL.

There is one problem with Cygwin - it's covered by the GPL. See http://cygwin.com/licensing.html: "By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all."


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?

On Fri, 3 Jan 2003 05:30:39 +0000 (UTC), Mark Evans wrote:
> You'd be amazed at what would happen if DMC were open-sourced!

Hmm, the source-code for OpenWatcom has been released a few months ago and AFAIK no one has even touched the C++ compiler source code. Why should it be different for DMC?


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?

1. Have you taken a look at CMake www.cmake.org for a portable approach towards simplifying complex build scripts?

This is slightly off-topic request, but has anyone thought about creating
DMC prj/opn files for CMake?
Walter, how about modifying the IDE to use 'text' version of .opn file
instead of the current binary one?

I have requested this one earlier too, so that we can put the opn files in cvs. This way, any changes in the settings could also be tracked. Without this, the use of IDE is severely limited and only makefiles have to be used. (Also, the opn files were 'touched' when IDE was closed even if the settings were not changed....I don't know if that has been corrected.)


2. If the 'binary compatibility to gcc' is left aside, will the porting be quicker? Why is the binary compatibilty a limiting factor?

3. If we can live without gcc 'features' under Windows, surely we can under Linux! DMC features are good enough.


"Walter" <walter@digitalmars.com> wrote in message news:av304o$1cn1$1@digitaldaemon.com...
>
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:av2in5$15p3$1@digitaldaemon.com...
> > You would be asking those people to re-write all their make scripts and
> such.
> > Not likely.  They're using Cygwin for a reason:  it lessens code
> maintenance
> > tasks.  It provides a standard Unix environment on Windows.
>
> While I'm sure those are a significant chuck of Cygwin users, I don't see that issue come up as the reason - I've never seen them say they feel trapped into using Cygwin because of the scripts.
>
> > So you would be asking them to drop their beloved Unix environment.  The
> only
> > way around that would be a version of DMC which uses Cygwin headers and
> the
> > POSIX-compliant Cygwin.DLL.  That's effectively a Linux port anyway;
might
> as
> > well do the real thing!
>
> To me, that's Cygwin's greatest drawback. If you're going to write a professional quality product and ship it on Windows, it ought to be a Windows app from the ground up. I've found I've been able to tell a Cygwin built app just by running it. It has a linuxee feel to the user interface (even the command line ones), the file handling isn't quite compatible
with
> windows file systems, the command line string handling isn't right, it doesn't handle windowy things like Ctrl-Break right, etc.
>
> > Right now, with G++ supported on both platforms, it's a rather obvious
> choice
> > for cross-platform work (flaws notwithstanding).  All DMC need do is
offer
> an
> > alternative for cross-platform work.
>
> I've written professional products that work on both linux and Windows.
I've
> never felt a need to use Cygwin to make that happen on the Windows side.
But
> I can see the appeal of using the same compiler on both platforms.
>
>
> > I venture that 80% or more of the cross-platform groups in existence are
> using
> > MSVC6 for Windows support and G++ for Linux support.  This includes
> OpenOffice,
> > complete with their horrific build scripts.  The chances of those
scripts
> being
> > rewritten for another Windows compiler are nil.
>
> <g> Sometimes I think I'm the only one who shuns complex build scripts.
I've
> seen some that used bizarre combinations of Perl, bash, C, awk, what-have-you. Just to build the program, you had to find/load tons of
other
> software (and of course the scripts were sensitive to particular versions
of
> all that software, arggh). When I finally figured out what all those
things
> were doing, it was easy to replace them with a straightforward makefile. Now, granted, DMC++'s runtime library has some execrable build scripts for the RTL, but I've been rewriting them as I incidentally need to do other work on them.
>
> Don't get me wrong, I'd love to make a full-up linux version of DMC++. The trouble is I am completely maxed out supporting 4 professional level compilers. I do the tech support too (and I'm very grateful when others
here
> step in and help out!) Ask other compiler vendors how many engineers they assign to just one product <g>.
>
> Doing a linux port is not easy. It would have to be binary compatible with gcc's output, and would have to have much of the extensions added that gcc has.
>
>

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:av375v$1gek$1@digitaldaemon.com...
> You'd be amazed at what would happen if DMC were open-sourced!

The D compiler is open source. But it's a lot less embarassing than the DMC source, which shows the effects of successive waves of rewrites in different styles by myself :-(

Christof Mee wrote:
>Hmm, the source-code for OpenWatcom has been released a few months ago and AFAIK no one has even touched the C++ compiler source code.

Two or more is always greater than one, which is what DMC has today.  The jump from one person to two is a huge quantum leap.  It won't take 100 developers on DMC to improve its prospects as implied by your remark.  (No offense intended Walter, we all know you're the greatest, but even Superman can't be in two places at once.)

>Why should it be different for DMC?

OpenWatcom has been on my radar screen for years now.  One reason I use DMC is that OpenWatcom has never done a real open source release!  So your premise is flawed in that sense.

They're entangled in licensing and copyright issues.  They have not released all the source code AFAIK.  You still need the old Watcom commercial stuff --- which is no longer for sale!  What they have released to date are "patches" over top of the legacy Watcom commercial distro.

An equivalent situation expressed in our terms would be that "OpenDMC" would only work for owners of original Symantec C++ software.

So the size of the OpenWatcom development team at this point is limited to

- people who own original Watcom tools before Watcom stopped selling
- and are interested in the open source release
- and have time to devote to the project
- and have skills to write a C/C++ compiler

which limitations thin the herd rather substantially.

Believe me, if Walter open-sourced DMC for a Linux port, the crowd would gather. If at all feasible, a good time to do that might be after he's finished with the current round of improvements on namespaces and templates.

In the Mythical Man-Month there is the idea of a system architect serving as a central switchboard for development teams.  He doesn't do everything himself, but supervises to ensure quality, consistency, and other Good Things.  This arrangement works well.  It has kept Python going for over a decade (Guido is the switchboard).  I think a similar model could work for an open-source release of DMC.

Besides that would give Walter more time to work on his D project.

Mark