alen@crash.cts.com (Alen Shapiro) (11/26/90)
What follows is a (mostly) unemotional report of difficulties to
date with Microsoft C and SDK. The cost to me and my company of
having to do Microsoft's QA job has been enormous. I have a task
of porting a 250k program that runs on the mac and sparc into the
MS windows environment and it has proved to be extremely
difficult. The non-windowing version of the program took < 1 day
to port to Turbo C and 4 days to port to MSC6.0. I support one
set of sources for mac/SPARC/TC/MSC, heavily #ifdef'd, making
full use of makefiles to set up for the different environments.
I know that Microsoft's development environment is complex but
software engineering may be made almost painless even in complex
environments given a little care by the compiler writers.
REPORT FOLLOWS;
1) nmake uses up global heap....a "multi C-module nmake" will
fail with an out-of-memory error, restarting will continue
on for a while and fail after a few more modules have compiled.
Solution ... use "nmk" (especially important when compiling
within windows itself).
2) trailing characters after a #endif cause warning messages
that may lead to "compiler fatal errors" trying to access
nested include files (in documented cases - not always). Turning
off warnings -W0 allows the compile to complete. I know
"#endif token" should read #endif /* token */ to be ANSI compatable
but that should not cause the compiler to baulk.
3) /NOD followed by windows library inclusion causes several BAD
things to happen...a) some functions are lost (halloc, hfree,
perror, system). There should be defaults to take the place
of these in a windowing environment. b) the following other
nasty things happen...
4) fprintf(stde{err,out}) is not supported under windows 3.0. Why
did microsoft not provide a standard text window into which these
messages could be thrown. I've just spent 3 days building a wfprintf
function to emulate fprintf() in a scrolling text window in
the presence of proportional fonts and including the ability to
scroll. I should not have had to do this. (I'll post the package
to this group (if response indicates it would be useful). It
is unsupported and I'm sure the MS gurus out there can improve
on it.)
5) Why do I need 2 compilers 1 for development and the other for
production? Why is the standard comiler so slow (an hour to
compile on the PS2/80, (15 minutes on the macII and 5 minutes
on SPARC))? Why does the development compiler (-qc) not work
in so many cases?
6) Using SDK, every source file seems to be placed (automatically)
in its own segment. I have a 40 module program I'm trying to port
from mac/sun to windows. The compile line I used with non-windows
MSC now gives me an error 1063: (with no error message - just
the number). Looks like -qc is running out of space now that
"windows" options have been included. So switch off -qc for those
modules that fail with this message.
Now all the modules compile, the next message I see is is "too
many segments" - back to the manual.
Build 2 new lines per C module in the makefile to specify segment
groupings (-NT) for each of the 40 modules. (note I have now
dramatically over complicated my makefile - I'd have preferred
to specify the segment name in the C module (have you seen the
manual pages on this? - talk about "overtinked")) and #ifdef'd it -
(#if defined(dos) && defined(WINDOWS) #segment SEGNAME #endif /* */))
ASIDE...I did this previously using the "(module1 module2)"
linker overlay spec. Seems that this spec is meaningless when
windows is used and does not result in a segment grouping
specification....Microsoft - WHY NOT?...(they could even avoid the
need for .DEF modification by choosing sensible segment-type defaults)
....back to the story.
Now I need a .DEF file to tell windows how to treat the segments
- ok I can live with that. Now I need to recompile everything....
Guess what, pass 1 of the compiler runs out of heap. The manual
says use C1L with the -B1 flag.
Now -qc spits out this message -Os - unrecognized parameter. - OK
I can live without space optimization, remove the flag.
Now I get -NT unrecognized flag - that means I can't use Segment
naming with -qc (the whole point of this diversion) under the C1L
compiler. Remove -qc and I'm back to 1 hour full compiles
IN DEVELOPMENT MODE. Not acceptable. (But required - thanks for
providing me with -qc Microsoft :-() ).
EMMOTIONAL STATEMENT WARNING...
Microsoft - did you fail to provide a version of -qc with the
C1L compiler that functions the same as the non-large version?
Was it a difficult thing to get right?
....EMOTION OFF
7) Why is there no SDK phone support. I'm classifying these problems
as compiler related and am going through the C6.0 support channels.
I'm sure some of them will be deflected (wfprintf) into the
"pay me more money and I'll tell you the answer" category. Right
now I feel that the cost to me and my company has been too much
to allow that response to succeed.
I still do not have a ported product but I'm getting closer (I
think). IHMO I've had to put up with far more pain than I should
have from the advertised "Professional Development Environment"
that I've had to buy from Microsoft in order to be SAA
presentation compliant.
NOW A REQUEST. I know this posting comes across as a strong
criticism of a product that must have been difficult to engineer.
I have a job to do and am "working the mirrors" to get that job
done in a robust manner. I do not believe I have overstated any
of the difficulties I've been having but I've not had time to
fully track down their cause in all cases. If there are solutions
to these problems that I've missed I'm all ears, please email me
or post to this group. I'll be faxing this letter to Microsoft
support soon and would like it to be as acurate as possible. I'd
be happy to include reports of other difficulties in my fax. I'd
like to be able to show Microsoft that there are developers who
are doing Microsoft's QA job for them and that need urgent
support and quality products.
If Microsoft is able to read this letter from the net...so much
the better...a point-by-point response is requested.
________________
EMOTION WARNING ON..... I try not to be a wimp,
when it comes to porting - there are always difficulties, I try
to write portable "standard" C code and have 15 years experience
in C development (including a PhD along the way). I am a Unix
guru (kernel and user), write mac-toolbox applications, PC
applications (including TSRs and graphics). I don't think I'm a
lightweight, but I am turned into a drivelling idiot by the CR*P
I've had to put up with from the development environment supplied
by Microsoft. Are there any kindred spirits out there or have I
finally entered wimphood?
EMOTION OFF...(I think)
--alen the Lisa Slayer (trying to turn a SPARC into a flame)
alen%shappy.uucp@crash.cts.com (a mac+ uucp host - what a concept!!)
alen@crash.cts.com