• Damian Dixon <damian.dixon tenetdefence.com> Jan 16 2001
• "Edward F. Sowell" <sowelled home.com> Jan 16 2001
• "Damian Dixon" <damian.dixon virgin.net> Jan 16 2001
• "Edward F. Sowell" <sowelled home.com> Jan 16 2001
• "Walter" <walter digitalmars.com> Jan 16 2001
• Damian Dixon <damian.dixon tenetdefence.com> Jan 17 2001

I've reposted the original message. The indentations in the newsgroup was
getting a little confusing.


On Fri, 12 Jan 2001 10:08:11 -0800, "Walter" <walter digitalmars.com> wrote:
 
 Damian Dixon wrote in message <1109_979295385 dilbert>...
 I appreciate all the work everyone here in the newsgroup is doing to




 workarounds for the template issues.




 
 Certainly, the work going on here to get a version of STL to work is great.
 



The STL part will need to be extended to include the hash containers
and to support DOSX,

This is probably the area I will concentrate on for now.

 A (rather dull) job I need to do is to get the manuals converted into usable
 html format, since my intention is to have all the manuals online instead of
 published. To do that, I ran all the .pdf files through adobe's pdf->html
 translator. Unfortunately, their software did a terrible job - the text is
 all there, but the formatting is a mess. All the html files need to  be gone
 through line by line and the formatting corrected by hand. Ugh. I could just
 say "use the .pdf files", but I don't like using them and I doubt other net
 people do either.
 


pdf format is acceptable for myself. However it does cause problems when
updating the manuals.

 The printf and scanf functions need to be upgraded to support 80 bit long
 doubles and hex floats. Any library changes need to be accompanied with test
 programs to verify that they work.
 
 I want to sort out and reorganize the library source tree so the old cruft
 is shunted aside and just the win32 stuff remains, and make it easier to
 build the library.
 


Will the new ANSI C++ header names be required? A work around exists via
STLport.

I think all the required changes need to be identified in some way, in
smallish chucks so that those that wish to help can do so.

We probably need to ensure that there is no duplication of effort.

 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
 SMAKE).
 


Why not use make that is part of the GNU tools?

 At issue also would be the compensation for any work people do that is on
 proprietary stuff. Due to licensing issues, I can't make it open source, nor
 can I transfer copyrights.
 
 



But then again compensation in one form or another can be a good motivator :->

Damian

 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
 SMAKE).


 Why not use make that is part of the GNU tools?


While very powerful, the GNU make is significantly different from make programs
with a DOS heritage, e.g., nmake, borland make, and smake. I had to do a
completely different
makefile for my project to cope with GNU make, while I was able to handle
diferences
between the others with conditionals.

Edward F. Sowell <sowelled home.com> wrote in message
news:3A649228.E21538F0 home.com...
 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues






 SMAKE).


 Why not use make that is part of the GNU tools?


 While very powerful, the GNU make is significantly different from make


 with a DOS heritage, e.g., nmake, borland make, and smake. I had to do a


 makefile for my project to cope with GNU make, while I was able to handle


 between the others with conditionals.

Damian Dixon wrote:

 Granted. However it is free to use and emulates the UNIX make quite well.


Agreed. But if we talking about a niche for DMC, which I understand will NOT
be free, perhaps it should not be aimed at the UNIX crowd. They will simply use

ALL of the GNU stuff, free. OTOH, there might be a demand for a MS alternative
development system that is comfortable for the Windows people.

My 2 cents!

Ed Sowell

The MAKE I have also has some customizations to make it work well with the
other tools I wrote. In particular, it handles arbitrarilly long command
lines, while other MAKEs are limited to the NT command line max of 255
characters.


Edward F. Sowell wrote in message <3A64DC64.2E50F13A home.com>...
Damian Dixon wrote:

 Granted. However it is free to use and emulates the UNIX make quite well.


Agreed. But if we talking about a niche for DMC, which I understand will


be free, perhaps it should not be aimed at the UNIX crowd. They will simply


ALL of the GNU stuff, free. OTOH, there might be a demand for a MS


development system that is comfortable for the Windows people.

My 2 cents!

Ed Sowell

On Tue, 16 Jan 2001 17:16:14 -0800, "Walter" <walter digitalmars.com> wrote:
 The MAKE I have also has some customizations to make it work well with the
 other tools I wrote. In particular, it handles arbitrarilly long command
 lines, while other MAKEs are limited to the NT command line max of 255
 characters.
 


ok, we will go with Walter's make :) 

Just could not stop myself mentioning the other one!

Probably should have as this has side tracked the real issue of how to manage
the required changes that Walter may wish people to help with.

 
 Edward F. Sowell wrote in message <3A64DC64.2E50F13A home.com>...
Damian Dixon wrote:

 Granted. However it is free to use and emulates the UNIX make quite well.


Agreed. But if we talking about a niche for DMC, which I understand will


be free, perhaps it should not be aimed at the UNIX crowd. They will simply


ALL of the GNU stuff, free. OTOH, there might be a demand for a MS


development system that is comfortable for the Windows people.




Not really true. We used to, but nearly all of our customers now use the
compilers
produced by the OS manufacturers. Very few of our projects are now on Unix.
The one I am currently working on finishes in May, and that's it no more Unix
projects, other then porting from NT to Unix. The main reason I like using DMC++
is the correctness of the code and libraries. I've had too many problems with M$
VC++, which has meant that I have had to disassemble the code produced to
figure out what has gone wrong.

My 2 cents!

Ed Sowell