Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!keithro From: keithro@microsoft.UUCP (Keith ROWE) Newsgroups: comp.windows.ms.programmer Subject: Re: Open letter to Microsoft re: SDK and C6.0 (long) Keywords: sdk msc6.0 compiler windows nasty horrible stuff Message-ID: <59623@microsoft.UUCP> Date: 7 Dec 90 00:32:15 GMT References: <5880@crash.cts.com> Reply-To: keithro@microsoft.UUCP (Keith ROWE) Organization: Microsoft Corp., Redmond WA Lines: 227 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)