Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!ucsd!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!lan!rommel From: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) 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: <5758@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Date: 28 Nov 90 15:00:08 GMT References: <5880@crash.cts.com> Sender: news@lan.informatik.tu-muenchen.dbp.de Reply-To: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) Organization: Inst. fuer Informatik, TU Muenchen, W. Germany Lines: 171 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 _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 */