Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!cfctech!teemc!ka3ovk!ki4pv!cdin-1!dsinc!lgnp1!penrij!soup From: soup@penrij.LS.COM (John Campbell) Newsgroups: comp.unix.xenix Subject: Re: cc on 2.3.2 Xenix with 2.2 Devel Sys Summary: 2.2 vs 2.3 DS CLARIFICATION Message-ID: <74@penrij.LS.COM> Date: 13 Jan 90 02:27:43 GMT References: <533@runxtsa.runx.oz.au><70@penrij.LS.COM><2259@promark.UUCP> Organization: penrij, Perkasie PA Lines: 48 In article <2259@promark.UUCP>, mark@promark.UUCP (Mark J. DeFilippis) writes: >In article <70@penrij.LS.COM>, soup@penrij.LS.COM (John Campbell) writes: >> Are you using curses? All too often the stack is not large >> enough for the dynamic (stack resident) tables used by curses. >> I'm not sure this occurs for the '386 product, but I _have_ >> had lots of problems with this in 286 code. >Shouldn't occur. The 80286 compiler version uses a fixed stack size >(I believe it defaults to 2000 hex bytes). It could be expanded with the >fixhdr -f command, or there is a cc option. 386 compiled executables >have variable size stacks and do not suffer from the limitations that the >286 does. Actually fixhdr -F xxxx or cc -F ... Anyway, on the 286 the stack _is_ fixed in size and often needs the stack extended past 3000 (hexadecimal, which is what the -F option expects). >BTW, on this box I am running SCO XENIX 386 2.3.2, with DS 2.2, and have not >experienced these core dumps. I run all kinds of stuff from Netnews, smail, >to filepro and Informix, etc... And if anything is going to core dump it is >going to be an Informix Esql/C program :-) My experiences are equivalent. Everything was working until I upgraded the DS to 2.3, then all hell broke loose. DS 2.2 is equivalent to Microsoft C 4.x whilst 2.3 is Microsoft C 5.x. I at least knew how to work around the bugs in 2.2. I also found some funny shift stuff that needed attention so I had to patch around that with an assembly language routine. I also discovered that in grafting on 386 code generation into the C compiler, Microsoft's ability to generate usable 286 code got pretty bad. -- Flame On! Using Microsoft and working in the same sentence can get you lynched. Like Intel, Microsoft can't get the first 7 revisions (or steps) of a product to work without bugs. Funny, isn't it, that Motorola's chips always work correctly? -- Flame Off! Please forgive the flames. I spent about 2 years working on the internals of Thoroughbred BASIC and had to make it work on both 286 and 386 boxes. I consider myself lucky that I didn't pull DOS duty... ------- John R. Campbell ...!uunet!lgnp1!penrij!soup (soup@penrij.LS.COM) "In /dev/null no one can hear you scream"