alen@crash.cts.com (Alen Shapiro) (12/05/90)
Thanks for all the replies and encouragement. wfprintf will be packaged up and shipped to this group within the next few days. I've just received a reply from a Microsoftian (polite term) Peter Golde who has some very useful suggestions. I'm posting this reply in case others out there in net-land need to use these hints. I'm also posting my response because I'm taking this discussion further with microsoft support and value the feedback that this forum has provided. Lines from my original posting are marked "> >", Peter's reply lines are marked "> " and unmarked lines are my latest response to Peter's points. The posting is long so prepare to use your net-veto.... ____________________________________ Peter, I really appreciate the time and effort you put into this reply. I have yet to receive an official reply from Microsoft (I faxed this letter 2 weeks ago). I'll follow up with tech support tomorrow. I would very much like to discuss some of the points you raise in the context of "portability", "ease of use" and "adherance to standards". I have received a large response to my posting, enough to indicate that Microsoft should seriously consider looking at these issues if it intends to have the C development community view it as a long term provider of devlopment tools. One of the respondants suggested that I request a "downgrade" to MSC5.1 because I would soon run into code-generation problems too. I have replied asking for specifics on that one. I do not mean especially to single out Microsoft for possible failure in the above contexts. At the moment however, they are the only game in town when it comes to windows development and I believe they have a responsibility to provide a quality product. > In article <5880@crash.cts.com> you write: > >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... > > Most of these function are meaningless in the Windows environment. > system() makes no sense since there is no command line interpreter, > while perror() makes no sense since there is no standard output > device by default (strerror() is still useful and available). > halloc() and hfree() can replaced trivially by the Windows 3 allocation > routines GlobalAlloc, GlobalLock, and GlobalFree, assuming you > are running in protected mode windows. However, much like the Mac, > memory allocation is a complex issue in Windows. > I agree that there may be no use for these programming paradigms in a real windowing world, but in the cause of portability wouldn't it be nice if standard C things continued to exist from one C environment to the other, especially (as you point out) since there are some relatively easy ways to mimic their behavior. Lets take these point by point since each is slightly different. 1) system(); this call may be mimicked by using WinExec with a string (like system's parameter and a SW_SHOWNORMAL. Having no command line is not the issue. 2) perror(); need not be directed to stderr for it to be implemented, a root dialog alert could have been mapped to this function. 3) halloc(); and hfree() may not be mapped to Global calls since this space is not garbage-collected when the application quits. I have tried to mimic this behavior using GMEM_DDESHARE|GMEM_FIXED|GMEM_NOCOMPACT and am rewarded with a fatal runtime error. In all these cases wouldn't it behove Microsoft to provide safe mapping of their MSC6.0 standard functions (I know halloc/hfree are not standard C but they are MS's way of allowing > 64k chunk allocation). My job as a porter/developer would be made much easier if I didn't have to learn the rules according to SDK after having done so for MSC6.0. > >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.) > > Presumably because a scolling text window is not a very intuitive > user interface; dialog boxes, message boxes and the like are preferred. But it can be done (I know - I have done it) and the response from the net indicates that it would be a welcome addition to the slowly accumulating body of user-contributed software. Scrolling text may not be very intuitive, it may cause the user to read (sometimes slowly), but not to support the facility redefines the C language and makes porting more difficult. If nothing else than as a debugging aid (I do not have 2 monitors and cannot run codeview) scrolling text is vital. (Please don't tell me to use MessageBox instead because I cannot debug a loop to 1000 without 1000 mouse clicks that way!!). MS did not however completely disable the use of the std streams, they left their tokens available so that the first real file-stream assignments would get them, thereby making it impossible to tell if a printf was originally destined for a console stream by intercepting the call. e.g. #define fprintf wfprintf fprintf(stdout, .....) wfprintf will see its first argument as stdout, but was this a real call to fprintf(stdout, ...) or was it a call to fprintf(second_file_I_opened, ...) > > >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 "standard" compiler is engineered for very high levels of optimization > and capacity, while the "quick" compiler is for smaller file which > don't require optimizations. The tradeoffs are very different. In > particular, the "standard" compiler has three seperate passes, while the > "quick" compiler has only 1 (I believe). Also, unlike many other > environments, the "standard" compiler has some optimization on by > default; specifying (-Od) will speed it up. > I was letting my sarcasm show a bit here (sorry). I realise that MS had a reason for producing 2 compilers but shouldn't they have taken care that it functioned similarly to the production version. I cannot use the "quick" version because it quickly gives me fatal errors that are not there. I'll try the -Od flag though and the hint is much appreciated. > >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. > > This can be alleviated in several ways. The "/SEGMENTS" command-line > switch to link will up the segment limit to allow more segments > in you program (as clearly stated in the on line help for the "too > many segments" message). > That was another of my gripes (unvoiced so thanks for the reminder). I have the editor on the screen, a manual on my lap and I have to switch context, exit the editor, load the mouse driver (if I want ease of use), then get into the help system, just to find out what the errors mean. How about putting this vital piece of information where it would do the most good. On Paper. > Another easy way to decrease the number of segments is to use the > "/PACKCODE" and "/PACKDATA" switches which combine segements together > up to a specified size; this will dramatically reduce the number of segments > in your program. > > > 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. > > The (module1 module2) syntax for overlays is completely different and > unrelated to the issue of segments: segments are no overlays and > never have been. Using this syntax would make no sense. Sorry - but using this syntax (with a different semantic) makes very good sense. Since overlaying code is not necessary in windows (if you are using enhanced 386), the syntax may automatically be used to indicate segments, since if it denotes sensible overlays it surely denotes sensible segments. If in non-enhanced mode, wouldn't it make a sensible default to put one segment per "overlay" rather than one segment per source module? Can't I have a #pragma segment <name> so that I can assign modules to segments without involving complicated (incorrectly documented?) options... I did not use /NOP and the docs say /PACKC is on by default. Why do I get too many segments with a 250k program at 64k per automatically packed segment? > > Segment-type defaults can be set in the .DEF file using the > "CODE" and "DATA" directives. > > > 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 :-() ). > > -NT is compatible with -qc, but -B1 isn't (-B1 directs the compiler > to use a greater capacity first pass, which doesn't make much sense > for the one-pass quick compiler). Where is this described? why is -qc accepted as a legal arg while the error message shows -Os and -NT as the culprits? Why is there no large-model equivalent of -qc that does not run out of space under fairly normal conditions? Why, when it does run out of space, is the consequence a "can't find include file" error message? I suspect that including normal windows compiler options runs the -qc compiler close to its limits regardless of the size of source file. > > There are several steps you can take to alleviate capacity problems > with the quick compiler if going to the regular compiler is unnacceptable > to you. The best is divide your source code into smaller files. > It's hard to give a good guideline for number of lines, since coding > styles vary so much. If you are including windows.h, you can > dramatically lower the symbol table space used by defining some of > the constants listed in the header of the file which prevent inclusion > of various sections (NOKEYSTATES, NORASTEROPS, ...). This will also > speed up compilation a fair amount. > Here I would like to thank you again, a combination of all of the above put me back on -qc. Only a few modules could not be coaxed into -qc compliance, but that is better than all of them. > >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 its a question of being wimpy, but you have to realize > that Windows programming is very different from Unix or vanilla MS-DOS > programming, while being more akin to Macintosh style application > programming. Expecting a port in a few days is simply unrealistic, > given the differences in application structure. I tried to give my credentials in order to make the point that I have seen much of the C environment "world". The ports to the other non-windows environments took slightly less than one day each, To MSC 6.0, 4 days. On the mac, adding in the toolbox code took another 2 days, compared to (under SDK) an additional 3 days to build wfprintf, 2 days to get the modules to compile under compiler space constraints and another 2 days fiddling with the options that would allow the program to link (including overlays and segmentation). I have no complaints about the Windows 3.0 paradigm, just the tools provided to make it play. BTW, the reason I DO expect to port in a few days is because I have done it before on better engineered compilers and environments. But now here comes that "ease of use" point again. I have had to learn some strange and "wonderful" things about the MS C compiler, some of which were badly documented or undocumented in order to "coax" the compiler to deal with code that works, without modification, on 2 other systems and 3 other compilers (including the mac under LSC4.0). Does that not suggest that there is something wrong with MSC? These other compilers have provided mechanisms to cope with segmentation, overlaying, internal compiler memory allocation, speedy compilation, compliance with standards, internal consistancy of options and accurate error reporting. Time for MS to start providing tools for the programmer, not hurdles that they must cleverly surmount. > --Peter Golde (petergo%microsoft@uunet.uu.net) > > I speak for myself, not for Microsoft Can I reasonably expect Microsoft officially to respond to these points? --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
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (12/05/90)
In article <6081@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >But now here comes that "ease of use" point again. I have had to learn >some strange and "wonderful" things about the MS C compiler, some of >which were badly documented or undocumented in order to "coax" the >compiler to deal with code that works, without modification, on 2 other >systems and 3 other compilers (including the mac under LSC4.0). Does >that not suggest that there is something wrong with MSC? These other >compilers have provided mechanisms to cope with segmentation, >overlaying, internal compiler memory allocation, speedy compilation, >compliance with standards, internal consistancy of options and accurate ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Joke. I have heard from Mac programmers, that, for example, their C compiler syntactically accepts prototypes but does not use the information that they provide in ANY way. This is not compliance with the ANSI C standard although ANSI C source files are accepted. :-) Kai Uwe Rommel -- /* Kai Uwe Rommel * Munich * rommel@lan.informatik.tu-muenchen.dbp.de */
petergo@microsoft.UUCP (Peter GOLDE) (12/12/90)
In article <6081@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >I've just received a reply from a Microsoftian (polite term) Peter Golde > who has some very useful suggestions. I'm posting this reply in case others >out there in net-land need to use these hints. I'm also posting my >response because I'm taking this discussion further with microsoft >support and value the feedback that this forum has provided. Since my private mail response was posted without my knowledge or consent, I'd like to make it clear that I have no current affiliation with the Microsoft C or Windows groups at Microsoft, nor do I have any knowledge about these products not gained from publicly available documentation. Furthermore, I am not a product support person nor I am paid to do any product support. Hence, please do not send mail to me requesting response (unless in response to a posting or mail message from me, of course), since I don't have the time nor the expertise to answer questions about windows. --Peter Golde