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.comtom@mims-iris.waterloo.edu (Tom Haapanen) (11/28/90)
Alen Shapiro <alen@crash.cts.com> writes: > 1) nmake uses up global heap.... ...or use one of the commercial makes, such as MKS or Opus. > 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. Take a look at tty/wstdio.c in the sample sources --- there is source right there! There are good reasons for not including standard i/o in Windows --- and Windows apps shouldn't be doing that kind of thing anyway! > 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? An hour?!? Our 25,000-line application takes 16 minutes to compile, link and rc on a 386/25 (with a 1 MB SmartDrive) with MSC 5.1 and default optimization. Are you using a disk cache? Is that a 16 MHz PS/2-80? Or is your application really immense? We don't use -qc --- why bother when even -Ox is fast enough? [ \tom haapanen --- university of waterloo --- tom@mims-iris.waterloo.edu ] [ "i don't even know what street canada is on" -- al capone ]
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (11/28/90)
In article <5880@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >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. That's a complexity problem. There seem to be much programmers asking for better optimizing compilers (instead of trying to write better code :-) and MS follows them (I found C 5.1 optimizing good enough). The new optimizer code seems to make this compiler really difficult to maintain. Each of the optimizations already caused be problems by generating wrong code (I already sent several bug disks to MS). And because MS C 6.0 can be used for *ANY* PC development (unlike Borland's C), i.e Windows and OS/2, it gets complicated even more. >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). That's a limitation of DOS (640k per DOS app+DOS itself). >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 These functions is simply unavailable in Windows. There are replacements, like WinExec() or GlobalAlloc(), but they require more parameters (and there is no reasonable default for them) or a different style of programming (-> Memory management under Windows) >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.) There is a sample TTY window code among the SDK sample sources. Also, there are little applications for this besides terminal emulators. This style of output does not fit very good into the Windows environment. >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? The incremental compiler does not very often work with Windows code because it is a one-pass (at least, one-.EXE :-) compiler that will get a heap overflow because of the huge WINDOWS.H. It is better suited to OS/2. The standard C compiler with -Od (no opt.) seems to me to be fast enough for Windows development. The speed difference with or without optimization can be dramatic. >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. See previous note. > 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 /* */)) When using medium model you get a default module name of <basename>_TEXT. MS suggests to group modules together to create segments of ~4k each. This has to be done by using -NT and segment specs in the .DEF file. This segment size improves system performance at least in standard and real mode. > specification....Microsoft - WHY NOT?...(they could even avoid the > need for .DEF modification by choosing sensible segment-type defaults) > ....back to the story. The segment-type defaults of the linker are best-suited for OS/2. > 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 I would suggest you to use the standard compiler (-qc works better under OS/2) WITH NO OPTIMIZATION (-Od). Using no optimizations is usual for development and using optimization for development may cause you also debugging problems (code may be moved due to loop optimization making it impossible for CVW to associate the code with it's source). I am using C 6.0 without -qc but with -Od all day for Windows development and it works flawlessly. > 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 An incremental compiler is not easy to implement with the memory restictions of DOS. The current situation of Windows development clearly shows the problems of DOS as a development environment - it is nearly unusable. I am using OS/2 on my private machine and there all the compilers, tools etc (even PWB) work flawlessly and fast. It is difficult to set up a machine for a development environment but still be able to run all of the tools without touching memory restrictions. The best would be cross-development with an OS/2 machine which provides disk access for a DOS machine running Windows which is only used for debugging. As you may notice, all of the tools in the SDK are bound applications that run under both DOS and OS/2 (except the utilities that run under Windows, iconedit, dialog, heapwalker etc.). Developing under Windows in 386 mode is also nearly impossible because it crashes too often (this would at least allow to open some other program without having to terminate the editor etc.). >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. You are right. The support by MS is rather poor. This may be related to the fact that they got a boom with Windows 3 they never had before. >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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's nearly impossible with Windows (this is my experience). >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? Many of the problems you reported are related to memory size restrictions. Others are related to the programming philosophy of Windows. I know from others that it is difficult to adapt to this one when coming from other systems like Unix, VMS or even the Mac. Perhaps OS/2 PM would fit better (at least for the Unix people as it is very similar in it's features and not this restrictions like Windows), this is my experience. As I wrote above, software development under MS-DOS suffers from that operating system :-). >--alen the Lisa Slayer (trying to turn a SPARC into a flame) Kai Uwe Rommel (I am student of computer science but already working in my spare time for Windows development in a small software company in Germany) -- /* Kai Uwe Rommel * Munich * rommel@lan.informatik.tu-muenchen.dbp.de */
n8443916@unicorn.cc.wwu.edu (John Gossman) (11/29/90)
In article <5880@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >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 . . . >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). At least Microsoft finally came out with a MAKE that really is a make, instead of that bleeping non-standard make they shipped for years. I would suggest PolyMake (which has some nice makefile extensions and runs on UNIX, DOS and many other platforms. > ... Specific windows related problems deleted > >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 I've been fighting MSC since 3.0 (which actually wasn't bad by the standards of those days. The latest incarnation is slug slow on my 25MHZ 386, and I've given up reporting bugs to Microsoft, faster and safer to just ifdef special cases for MSC . >think). IHMO I've had to put up with far more pain than I should I am continually amazed that Microsoft can develop their own products using the low quality tools they ship. I often wonder if the programmers all have copies of Turbo C in hidden directories on their systems and can HOT KEY back to MSC when a supervisor walks by :-). >________________ >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) I can and will develop using the Microsoft tools, and am having very few problems right now porting our ~60,000 line CAD product to windows. On the other hand, Microsoft is by far my least favorite development platform (others are Amiga, UNIX, and Turbo C for DOS). Living in Washington I continually hear programmers glorify Microsoft, and am forced to put up with the often arrogant villification of Borland and other compiler makers by Microsoft techs. Some of these idealogues should try working with other environments, I think it would change their minds. The GOOD news is that Borland has gotten over their own ideological prejudice against Windows and will ship a C++ toolkit that is a complete repacement for the Windows SDK early next year. I hope to quickly toss MSC 6.0 back on the garbage heap next to my bug ridden copies of 5.0 and 4.0, and the SDK with it. One more comment. My favorite Microsoft product is OS/2. It is also just about the only one that Microsoft can't seem to sell :-(. // *************************************************************** // John Gossman SoftSource (206)676-0999 Phone WWU Math Dept. My employer stands behind all my opinions, except in public. // ************************************************************** //
n8443916@unicorn.cc.wwu.edu (John Gossman) (11/29/90)
In article <1990Nov28.125836.10515@watserv1.waterloo.edu> tom@mims-iris.waterloo.edu (Tom Haapanen) writes: >Alen Shapiro <alen@crash.cts.com> writes: > >> 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? > >An hour?!? Our 25,000-line application takes 16 minutes to compile, link >and rc on a 386/25 (with a 1 MB SmartDrive) with MSC 5.1 and default >optimization. Are you using a disk cache? Is that a 16 MHz PS/2-80? Or >is your application really immense? > >We don't use -qc --- why bother when even -Ox is fast enough? I don't use -qc either, but that's because it doesn't work. Two comments: MSC 6.0 is visibly (even dramatically) slower than 5.1 was; MSC 5.1 is very slow compared to most other commercial compilers. You seem shocked at his 1 hour compile time (I am too), but are you really happy that you only wait 16 minutes to compile only 25,000 lines on a 386/25 (using caching and a SmartDrive)? Either Turbo C from Borland or Zortech C will compile our 60,000 line (largest build probably 30,000 lines after preprocessing) in about 7 minutes on a 386/20 with RAM drive. With MSC 6.0 I usually go out for lunch when doing a complete rebuild. The guy in my office porting to DEC 3100 laughs that he doesn't need to use make because it recompiles all the code while I'm waiting for one or two modules. What seems good is what you are used to--and I'm spoiled and glad of it. // *************************************************************** // John Gossman SoftSource (206)676-0999 Phone WWU Math Dept. My employer stands behind all my opinions, except in public. // ************************************************************** //
karl@ficc.ferranti.com (Karl Lehenbauer) (11/29/90)
In article <1990Nov28.125836.10515@watserv1.waterloo.edu> tom@mims-iris.waterloo.edu (Tom Haapanen) writes: >Take a look at tty/wstdio.c in the sample sources --- there is source >right there! It doesn't work right with large model, at least for me, and there are bugs in the scrolling optimization stuff where you can lose lines, but it served as an starting point for making one that works. >There are good reasons for not including standard i/o in >Windows --- and Windows apps shouldn't be doing that kind of thing anyway! Hmm, you can do stdio in DOS windows... Come on, it's very useful for debugging, and there are applications that need to have scrolling text, like terminal programs. Who says every application should have to have a graphical user interface? Maybe for the least sophisticated end-users, but it's nice to be able to quickly port a stdio-style program and not worry about doing a GUI front- end, at least right away (cf. xterm, the Amiga CLI, the amount of time you spend developing running under COMMAND.COM). -- -- uunet!sugar!ficc!karl (wk), "Any excuse will serve a tyrant." -- Aesop uunet!sugar!karl (hm)
jimad@microsoft.UUCP (Jim ADCOCK) (12/04/90)
In article <5880@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: |What follows is a (mostly) unemotional report of difficulties to |date with Microsoft C and SDK. I am not Microsoft, but rather a fellow user of C and the SDK, and I am sympathetic to the bulk of your complaints. |If Microsoft is able to read this letter from the net...so much |the better...a point-by-point response is requested. To the best of knowledge, there is no "Microsoft" to read and response to concerns expressed on notes streams -- although, if it were up to me, there would be people so assigned. I read notes to see what I can learn personally, and to help out in such small ways as my limited knowledge and power can be applied. However, reading and replying to notes streams is a very time consuming task, and my bosses make it clear they'd just as soon have me doing something else. I believe a lot of MS programmers do read these notes streams, and do take concerns and complaints expressed to heart. "MS" has "officially" acknowledged, I believe, problems with their C/C++ compiler development efforts. However, from what I seen the programmers on that effort are working very hard, and making their very best efforts. The "MS Development Environment" is insanely complicated, in my opinion, which is a big part of the problem. [external customers only see a small part of these complications, Thank God!] I will make my best effort to get some changes made in these areas, which will be to post and mail your complaints to the people best positioned to make some changes, and bend the ears of whatever managers I am privy to. I am sorry to say that this will probably not be enough to answer the bulk of your complaints, but I am just another grunt in the trenches like yourself. Hopefully someone better positioned to answer these complaints will respond here too. I just felt it would be cowardly to read these complaints and not make it clear that at least *some* action is being taken. [A fellow C/SDK user]
jimad@microsoft.UUCP (Jim ADCOCK) (12/05/90)
In article <59515@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: |In article <5880@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: ||If Microsoft is able to read this letter from the net...so much ||the better...a point-by-point response is requested. | |I will make my best effort to get some changes made in these areas, which |will be to post and mail your complaints to the people best positioned to |make some changes, and bend the ears of whatever managers I am privy to. |I am sorry to say that this will probably not be enough to answer the |bulk of your complaints, but I am just another grunt in the trenches like |yourself. Your complaints have been "pushed up the line" to Steve Ballmer, and people who know Steve Ballmer know he's insanely interested in making Windows a success, so I'm becoming more optimistic that concrete positive steps will be taken to fix the problems you're having. I'll report back as I hear more....
keithro@microsoft.UUCP (Keith ROWE) (12/07/90)
Alen's fax was received by Microsoft Product Support and his problems have been addressed. For the benefit of others who share his difficulties, I would like to post this response. Thank you for your comments. Working with a new environment is always tricky and this is especially the case with an environment as intricate as Microsoft Windows. Here are answers to a number of questions you raise in your posting. | |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). You are correct to use nmk in this case. This is one of a number of capacity problems you point out in your article. We are very aware of these limitations and are planning to alleviate them in the next release. | |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. We are planning to make this error a level 4 warning so that it can be shut off more easily. This is the first report of this problem. If you can supply our Product Support group with a case where these warning messages cause "compiler fatal errors", we will gladly work to isolate the bug. [ed. note - Alen has supplied this case and we are exploring the problem with him.] | |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... The Windows 3.0 environment does not support a number of DOS functions including halloc, hfree, perror and system. You can replace halloc and hfree with GlobalAlloc and GlobalFree (with some restrictions, see the SDK reference manual). We are working on an easier solution to this problem for the next release. | |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.) As Windows 3.0 becomes more popular, many people will want to move DOS text apps to Windows quickly. We are working on a solution for this problem and it will be available in the next release. | |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? We provide two completely separate compilers in the C 6.0 box: QC and C 6.0. QC is the same "quick" compiler we sell in the Quick C package. It is designed to generate code of acceptable quality quickly (hence the name :-). C 6.0 is the fully optimizing compiler that comes from C 5.x. Because it does a lot of global analysis it is much slower than QC but is roughly equal in speed to other compilers that generate similar quality code. Because they are separate compilers, their bugs are separate as well. If you find cases where they behave differently, we would like to hear about it. Please contact Product Support with your example code. C 6.0 is slower in DOS because the optimization pass is heavily overlayed and needs to swap in and out of memory frequently. You can remedy this to some degree by putting c2.exe (the optimizer) on a RAM disk or (better still) have a large disk cache (2 Meg or so). Running under OS/2 would also improve C 6.0's speed. Since you usually only need this for release builds, it may not be worth the RAM to try any of these fixes. | |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. QC does have capacity limits. You are correct to switch off QC for these modules. | 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 /* */)) A simpler way to overcome this problem is to use the /SEG:num option in the LINK line to tell the linker to allow more segments. | | 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. Actually, overlays and segments are very different things. Grouping modules for overlays does not say anything about the segments that that overlay will contain. The on-line help has an extensive discussion on using overlays (it's under the LINK index). | | 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 C1L is the large model first pass of the C 6.0 compiler. When you invoke this with the -B1 flag you are automatically getting the C 6.0 compiler and the QC options you mentioned will confuse it. That is, the -qc and -B1 flags are incompatible. This is not adequately discussed in the documentation and it will be clearer in the next release. There is no large model version of the QC compiler. It was a design decision to not include yet another compiler in the package because we felt cases like this would be rare. As I said before, we are working to provide a solution for capacity problems and it will be ready for the next release. | |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. We are looking into providing SDK phone support. In the meantime, you are right to direct your compiler related questions to the C6.0 support channels. You might also want to look into OnLine, our electronic support service. It costs, but for the time it saves you with problems like these, it will probably be worth it. | |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) I don't think you have entered wimphood - this is simply a new environment with its own way of doing things. Many things in Windows are different than in Unix or even the Mac, especially segmentation. If you have any further questions, don't hesitate to call our Product Support staff - that's what they are there for. thanks again for your comments, Keith Rowe Program Manager - C Languages Microsoft, Inc. | |--alen the Lisa Slayer (trying to turn a SPARC into a flame)
rick@kimbal.lynn.ma.us (Rick Kimball) (12/08/90)
From article <59623@microsoft.UUCP>, by keithro@microsoft.UUCP (Keith ROWE): > |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. > > We are looking into providing SDK phone support. In the meantime, you > are right to direct your compiler related questions to the C6.0 support > channels. You might also want to look into OnLine, our electronic support > service. It costs, but for the time it saves you with problems like > these, it will probably be worth it. Bzzzt .... Wrong!!! Keith. Online is a pain. First you have to sit down and write up your problem then submit it to a queue. Then you wait ... call back to Online ... ah no response ... hangup ... wait ... call back to online ... ah no response .. hangup ... Well you get my drift. Eventually someone responds with a question instead of an answer that usually goes like: Is you computer plugged in? Do you have your path set properly? Or some other obvious stupid question. ... The only thing that is worthwhile on Online are the programs from MSJ. In fact, usually ask in my service request to have the engineer call me at least I can ask a person some questions without getting stupid follow-ups. I've found that the questions I need answers to are related more to when MS is going to fix something than how to do something. Your mileage may vary. Rick
cgeisler@maytag.waterloo.edu (Craig Eisler) (12/09/90)
In article <59623@microsoft.UUCP> keithro@microsoft.UUCP (Keith ROWE) writes: >C 6.0 is the fully optimizing compiler that comes from C 5.x. >Because it does a lot of global analysis it is much slower than QC but is >roughly equal in speed to other compilers that generate similar quality >code. Sorry, I can't resist this. "roughly equal?". As an experiment, I used C 6.0 to recompile a pet project of mine (~28000 lines). Not only did it take over *twice* as long as Watcom C 8.0, but the executable that it generated didn't work (and no, I didn't have any of those ludicrous "unsafe" optimizations turned on). And Watcom C does indeed generate similar quality code (only the code they generate always seems to work, unlike C 6.0) "Roughly equal" my fanny. :-) >Keith Rowe >Program Manager - C Languages >Microsoft, Inc. craig -- Craig Eisler, still hiding from the real world. University of Waterloo, Waterloo, Ontario.