Path: utzoo!attcan!uunet!optilink!cramer From: cramer@optilink.UUCP (Clayton Cramer) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: Looking for experience with big project upgrades from MSC 5.1 to 6.0 Message-ID: <3789@optilink.UUCP> Date: 14 Jun 90 19:15:09 GMT References: <1990Jun13.132843.13966@Octopus.COM> Organization: Optilink Corporation, Petaluma, CA Lines: 85 In article <1990Jun13.132843.13966@Octopus.COM>, pete@Octopus.COM (Pete Holzmann) writes: > I'm working on a very large commercial software project using MSC 5.1 and > some assembler. It is complex, huge, hairy, etc. Doesn't use Windows, > but does use graphics, interrupts, EMS, lots and lots of overlays, etc. > > We're contemplating an upgrade to MSC 6.0, hoping for (a) smaller code; > (b) faster code; (c) better operation of CodeView under MagicCV; (d) fewer > bugs in the MSC compiler. Most especially (a). We have source code for > everything but our graphics library (GSS*CGI), which is hopefully not a > problem. > > Has anybody out there been through (or most of the way through) an upgrade > of a big pile of code from 5.1 to 6.0? If so, I (and probably others in > this newsgroup) would love to benefit from your experience! If somebody > from MicroSoft cares to comment on internal product upgrade experience, > or to summarize feedback from customers, that would be great too... > > 1. In general, did it go very smoothly? (i.e. no gotcha's vs. so many > gotcha's we cried for a month... :-)) No. There were continuing problems with the linker, but those seem to have gone away now. It *appears* that we needed to recompile code used to make libraries. There are also some new symbols associated with _chkstk, and if you have rewritten _chkstk, as we have, you will need to make sure that you have the following symbols present, or you will still get the standard chkstk from the library: __chkstk STKHQQ __aFchkstk __aaltstkovr > 2. What compiler switches did you end up using in order to have code > that always runs ok without tweaking things everywhere? (Or did > you end up tweaking everywhere?) The only problem with switches was that some code didn't work unless we disabled optimization with -Od. (I've already posted about this elsewhere). > 3. What kind of global tweaks were required? (i.e. under MSC 5.1, you > must make sure that any function definitions in an include file do > not span more than one line, or you'll break CV...) No problems of this sort. > 4. What kind of hassles have you had with auxilliary tools (linkers, > debuggers, etc.)? Does everything still work ok? We were using the Everex disk caching software, and it appears that it won't work in conjunction with the HIMEM.SYS driver and CodeView -- you start getting weird complaints about unrecoverable disk errors. Use the SMARTDRV.SYS driver instead of EVCACHE and it works fine. > 5. Do you have a general idea of code space saved, data space saved, > speed improvements? (Probably also in this category: rumor has it > that constants can be/are now compiled into the local code segment, > which would be a big win in an overlaid architecture; is this true?) If there is a size or performance improvement, it's not obvious. > 6. Ignoring the fact that in general you've got to upgrade your tools > eventually, was the benefit from upgrading more valuable than the > hassle, or was it more trouble than it was worth? (i.e., if you had > it to do over, would you wait if you could, maybe for 6.1, or even > switch to a different compiler :-))? > > Peter Holzmann, Octopus Enterprises |(if you're a techie Christian & are The new CodeView with 6.0 is a big improvement. Because it can take advantage of extended memory for symbol space, and apparently loads part of CodeView up there, we no longer need to use MagicCV to debug our humongous application; this is a big advantage, because it means we can now debug on 286 systems with extended memory; MagicCV requires a 386 system. Also, the new CodeView using extended memory is MUCH faster than using MagicCV and expanded memory. We also don't run into problems with too many symbols anymore, which means we no longer have to decide what modules we want to debug at any given time. Overall, it was worth the hassle to upgrade. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Pipe bomb: appropriate technology for living lightly on Mother Earth. :-) ---------------------------------------------------------------------------- Disclaimer? You must be kidding! No company would hold opinions like mine!