dennis@se-sd.sandiego.NCR.COM (Dennis Foster) (11/06/87)
In Article 9443 zeus@stratix.UUCP (Mark Mullin) writes: > > ... some stuff deleted ... > >3: MS isn't playing nice > When we aquired windows, we subscribed to MS Dial, an expense >of about $450 bucks, + Telenet. You have to do this, since phone >service keeps telling you that they can't answer questions but Dial >can. Dial is a nice trick. MS provides the computer, users post >problems and then solve them themselves. MS doesn't even say thanks. > We also have an account on CSERVE, where MS has a company >sponsored SIG including Windows. Funny, but MS doesn't even bother >to ensure that knowledge is equally represented on both Dial and CSERVE. >You get bits and pieces on each. > MS has made many promises about the upward compatibility of >Windows, and the development schedule. Well, Windows 386 is out, and >they said otherwise. The presentation manager calls on the PS-2 are >different than Windows, and they said otherwise. > Another source of information is the MS-Windows devlopers roundtable on GEnie. We have a DIAL account but use it rarely since GEnie seems to be much more responsive. Feedback is generally from other developers rather than from Microsoft and there seems to be less hesitence to say something that the rules (MS) say you shouldn't say (there seems to be a lot of evading the issues on DIAL). The GEnie RT is SYSOPed by an MS employee and does provide much information straight from MS (although his GEnie work is done on his own time). I don't understand the point about Windows 386. It uses the same API and user interface as Windows 2.0 which IS upward compatible with Windows 1.0x. Programs written for 1.0x will run on Windows 2.0 and Windows 386 WITHOUT change. The PM of OS/2 (which is not at all tied to the IBM PS/2 as you seem to infer) is another issue. Statements from MS indicate that developers can expect to invest about 10% of their original development costs to port a program from Windows to the PM of OS/2. The estimates we have for our applications is about 25% to 30%. I think MS's 10% estimate was really a "Low Ball" figure so as not to scare off too many Windows developers (BTW: I picked up that 10% number at one of the MS OS/2 seminars). > > ... more some stuff deleted ... > > >5: Stupid Things > A: WINDOWS.H > The include file that must be read in to every > windows program is quite large and significantly > increases compile time. When you take a 50+ module > system this grows to an insane amount of time. The WINDOWS.H file can be cut down significantly by including various #defines in your C modules that toggle out those portions of the WINDOWS.H file you don't require. On most of our modules this reduced our compilation time by over 50%. > B: Pascal Calling Conventions > All of the functions in your program that windows > will call, and all of the windows control functions > are defined using PASCAL calling conventions. For > a package apparently designed for the C environment, > this is a strange action. Designed for the C environment??? Maybe. You can, however, write windows applications in MS-Pascal or assembler. The reason I've heard most often from MS for using the PASCAL calling convention is efficency (the PASCAL convention is more efficient than that used for C). By using the /Gc switch on the invocation of the compiler, you don't even need to include the PASCAL keyword in your C source. The only functionality you loose is the ability to pass a variable number of parameters to a function (note that fprintf and the other C runtime routines are defined cdecl to allow them to function as you would normally expect). > C: Debugging > While I commend Microsoft for realizing that debugging > would best be done on a secondary display, they provide > symdeb as the development package. Why can't they > adapt CodeView for a dumb terminal. I don't care about > the graphic display, its the symbolic referance > capabilities I want. > As I understand it they provide support for symdeb (and not codeview) for memory reasons, not for technical reasons. Symdeb is more than adequate (I grant that it is not as nice as codeview). Note that even with symdeb, if you are debugging a large application, its easy to run out of memory. For example, when running our application with nothing else going on we have about 250K of free memory. Under symdeb, this number drops down to about Lawiv