jwg@duke.cs.duke.edu (Jeffrey William Gillette) (04/21/88)
Last year I was working on a large project with Microsoft C 4.0 in the large memory mode. Half-way through, I noticed that uninitialized global variables (the kind put in the BSS segment) were being mysteriously trashed at random intervals. A few weeks with CodeView, and I discovered that malloc() was allocating storage right over the top of uninitialized globals! A tar to Microsoft (then I had access to Dial) brought the answer that (I paraphrase), "We know there is a problem with uninitialized globals, others have told us of the problem, we will fix it with the next version of MS C." This year I am working on a smaller project for an independent client. I develop a program using the large memory model and MS C 5.0. All of a sudden, some uninitialized globals start being trashed at random intervals. I reach (by instinct) for CodeView, set a few watchpoints, and discover (surprise, surprise) that malloc() is allocating storage right over the top of uninitialized global variables! Probably a dozen UseNet aces have already pointed up the same problem. And, this may not be a problem for programs tht keep all their data in the DGROUP segment (I haven't done much with uninitialized data in small or medium models). My question is simply, when is Microsoft going to get the message that real world programmers don't use the small memory model all the time. Sure the medium model (a la Quick C) provides for far code and near data - give me a break! The opposite would have been much more useful! Now I no longer have access to Dial, and can no longer get the "official" Microsoft position on such subjects. Anyone want to venture a guess as to when Microsoft will get on the ball and give us a *REAL WORLD* C compiler that handles both initialized (DGROUP) and uninitialized (BSS) global data in a large data memory model? Until then, my perception is that one uses uninitialized global structures (in large data models) at one's own risk! Jeffrey William Gillette Jeffrey William Gillette uucp: jwg at duke.edu Duke University bitnet: DYBBUK at TUCCVM -- Jeffrey William Gillette uucp: jwg at duke.edu Duke University bitnet: DYBBUK at TUCCVM
alexc@psu-cs.UUCP (World Class Hacker) (04/22/88)
Hi there,
As you may have already know that Microsoft have tried to build a
good C-compiler for the IBM-PC ( Brain damaged ! ) env. REAL LIFE C
PROGRAMMER DO NOT DO MUCH C PROCOMMING ON PC's THEY USE UNIX OR U**N INSTEAD.
Of course, if your client only have access to PCs then you just have to find
a way to correct the problem.
* FRAME ON *
Let see you write a C compiler for the IBM-PC running MS-DOS WITHOUT ANY
MISTAKES ( 100% ERROR FREE ) on the first try ! ( NO ERRORS WHEN YOU TRY TO
COMPILE THE SOURCE CODE FOR THAT COMPILIER then you couse say ......... !!
* FRAME OFF *
Anyway, you could send e-mail to Microsoft and see you could get
an answer. Their e-mail path from our site is : tektronix!uw-beaver!microsof
Sincerely,
__ _
/ ) //
/--/ // _ _.,
/ (_</_</_/ /\_
-------------------------------------------------------------------------------
RETURN PATH : alexc@psu-cs.uucp
FRAMES > /dev/null
-------------------------------------------------------------------------------madd@bu-cs.BU.EDU (Jim Frost) (04/25/88)
In article <633@psu-cs.UUCP> alexc@psu-cs.UUCP writes: [response to a user's complaint about the state of Microsoft C] | As you may have already know that Microsoft have tried to build a |good C-compiler for the IBM-PC ( Brain damaged ! ) env. REAL LIFE C |PROGRAMMER DO NOT DO MUCH C PROCOMMING ON PC's THEY USE UNIX OR U**N INSTEAD. |Of course, if your client only have access to PCs then you just have to find |a way to correct the problem. I hate to burst your bubble, but there are quite a few PC's out there. This means a large market. This means money. As a programmer, I'm interested in maintaining a decent influx of cash. *That* is why people program for PC's. People use C on PC's because it's a flexible language that's pretty portable, which is also why it's used on so many other systems. Also note that the "PC environment" is not necessarily MS-DOS. UNIX also runs on PC's in various flavors, and so do other operating systems that aren't so popular. |Let see you write a C compiler for the IBM-PC running MS-DOS WITHOUT ANY |MISTAKES ( 100% ERROR FREE ) on the first try ! ( NO ERRORS WHEN YOU TRY TO |COMPILE THE SOURCE CODE FOR THAT COMPILIER then you couse say ......... !! Well, Microsoft C is on version 5.1. This means a minimum of 6 revisions of their compiler have gone out (1.0 - 5.0 major and now 5.1 to fix a plethora of bugs in 5.0). You'd think that after that many major revisions, most of the bugs would be gone, especially those which users have complained about repeatedly. | Anyway, you could send e-mail to Microsoft and see you could get |an answer. Their e-mail path from our site is : tektronix!uw-beaver!microsof Obviously you haven't dealt with Microsoft. Their response time and usefulness-of-responses leave something to be desired. jim frost madd@bu-it.bu.edu
cramer@optilink.UUCP (Clayton Cramer) (04/25/88)
> |Let see you write a C compiler for the IBM-PC running MS-DOS WITHOUT ANY > |MISTAKES ( 100% ERROR FREE ) on the first try ! ( NO ERRORS WHEN YOU TRY TO > |COMPILE THE SOURCE CODE FOR THAT COMPILIER then you couse say ......... !! > > Well, Microsoft C is on version 5.1. This means a minimum of 6 > revisions of their compiler have gone out (1.0 - 5.0 major and now 5.1 > to fix a plethora of bugs in 5.0). You'd think that after that many > major revisions, most of the bugs would be gone, especially those > which users have complained about repeatedly. > Microsoft isn't exactly a paragon of virtue in the software testing area, but there's a couple of mistakes in the statement above. V1.x and V2.x of the "Microsoft" C compiler were actually the repackaged Lattice C compiler. The only releases that I've seen from Microsoft were V3.0, V4.0, V5.0, and now V5.1. I will agree it's frustrating, and in many cases (V5.0 for example), it's obvious that the compiler was shipped before it was quite ready (hence the page after page of readme files on the distribution disks), but testing a compiler thoroughly is DAMN DIFFICULT! I do agree with all the nasty remarks about Microsoft's level of support. Clayton E. Cramer
sam@ftp.COM (Shelli Meyers) (04/26/88)
In article <21992@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes: > > Well, Microsoft C is on version 5.1. This means a minimum of 6 > revisions of their compiler have gone out (1.0 - 5.0 major and now 5.1 > to fix a plethora of bugs in 5.0). You'd think that after that many > major revisions, most of the bugs would be gone, especially those > which users have complained about repeatedly. I hate to burst *your* bubble, but I have heard rumors (from some of Microsoft's 5.1 beta sites) that 5.1 is still about as broken as 5.0. This is unfortunate for developers who would *like* to "keep up with the Jones'" as far as new industry-accepted compilers go, but how can you support something you can't even trust to use in-house yourself? Sad... c'est la vie. Shelli Meyers FTP Software, Inc.
loci@csccat.UUCP (Chuck Brunow) (04/26/88)
I don't understand this but I copy files from Sys V unix straight into Microsoft C, no changes, no fuss, no muss. MSC catches a few real errors that "mcc" let's by, but it works great.
chl@whuts.UUCP (LANG) (04/26/88)
With all the complaining about Microsoft (from bugs to lack of support), has anyone checked out the new assembler called OPTASM ver 1.0. I saw a brief review in Volume 7 Number 7 (April 12,1988) of PC Magazine on page 43. Sounds pretty good. It's much faster than MASM 5.0. Charlie Lang whuts!chl
chasm@killer.UUCP (Charles Marslett) (04/27/88)
In article <21992@bu-cs.BU.EDU>, madd@bu-cs.UUCP writes: > > |Let see you write a C compiler for the IBM-PC running MS-DOS WITHOUT ANY > |MISTAKES ( 100% ERROR FREE ) on the first try ! ( NO ERRORS WHEN YOU TRY TO > |COMPILE THE SOURCE CODE FOR THAT COMPILIER then you couse say ......... !! > > Well, Microsoft C is on version 5.1. This means a minimum of 6 > revisions of their compiler have gone out (1.0 - 5.0 major and now 5.1 > to fix a plethora of bugs in 5.0). You'd think that after that many > major revisions, most of the bugs would be gone, especially those > which users have complained about repeatedly. Actually, (for reasons not particularly interesting) Microsoft has only released 4 (or 6 if you count the two Windows/OS2 releases) and the numbers started with 3.0. Unfortunately, I think 3.0 was a bug free as 4.0, 5.0 and 5.1. Sigh . . . > jim frost > madd@bu-it.bu.edu Charles Marslett chasm@killer.UUCP
bturner@hpcvlx.HP.COM (Bill Turner) (04/28/88)
> I will agree it's frustrating, and in many cases (V5.0 for example), it's > obvious that the compiler was shipped before it was quite ready (hence > the page after page of readme files on the distribution disks), but > testing a compiler thoroughly is DAMN DIFFICULT! Yes, but when they can't (or don't) run previous test cases through the compiler to make sure they didn't break anything, then I say they aren't doing anywhere close to enough. There SHOULD be a reasonable test suit that should be a minimum test case, you'd think. --Bill Turner
markro@microsoft.UUCP (Mark Roberts) (05/17/88)
> In article <21992@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes: > > > > Well, Microsoft C is on version 5.1. This means a minimum of 6 > > revisions of their compiler have gone out (1.0 - 5.0 major and now 5.1 > > to fix a plethora of bugs in 5.0). You'd think that after that many > > major revisions, most of the bugs would be gone, especially those > > which users have complained about repeatedly. > > I hate to burst *your* bubble, but I have heard rumors (from some of > Microsoft's 5.1 beta sites) that 5.1 is still about as broken as 5.0. > This is unfortunate for developers who would *like* to "keep up with the > Jones'" as far as new industry-accepted compilers go, but how can you > support something you can't even trust to use in-house yourself? > > Sad... c'est la vie. > > Shelli Meyers > FTP Software, Inc. ------------------------ We would like to address some of the questions raised by these and similar recent articles appearing on the net. Mr. Frost states that C 5.1 is at least the 6th release of MS C. In fact C 5.1 is the 4th release of this compiler. Versions 1.x and 2.x were licensed versions of Lattice C (circa 1982). Microsoft developed its own compiler because of the need for higher quality code generation and the need to support the 286 instruction set for the development of XENIX. MS C 3.0 was the first retail version of this compiler. C 5.1 was not released as a "bug fix" version for C 5.0, but rather as an OS/2 development compiler. It is the first retail version which will run in protected mode and supports the generation of protected mode executables. C 5.1 does fix a number of problems from C 5.0; however, Mr. Frost's statement implies that these were problems of long standing, when in fact, the most serious problems (with in-line intrinsics and loop optimizations) could not have existed in previous versions of the compiler as these feature were added for C 5.0. Ms. Meyers claim about Microsoft not using its own products in-house is completely off base; her remarks can only be characterized as ill-informed at best. Some examples of Microsoft products built exclusively with C 5.0 and/or C 5.1 (some with the addition of some MASM code) include: MS C, QuickC and FORTRAN compilers QuickBasic 4.0 and Bascom compilers CodeView Debugger Utilities (Linker, Librarian, M editor, etc.) XENIX OS/2 (CMD.EXE and utilities) LAN Manager Presentation Manager Windows Windows Desktop Applications CD-ROM Applications (Project, XENIX Word, XENIX Multiplan) This is not an all-inclusive list but it should give you an idea of the committment Microsoft has to using C as its development language. (The Applications group does have their own C compiler, but this was motivated by the need for P-code generation to save space and to add 68K support, not because of any problems with the retail version.) These products represent hundreds of thousands of lines of C code running under C 5.x and we find the allegations of instability hard to understand and support in this light. This is not to deny that there have been some bugs, even some serious ones, in our compiler. All compilers have some, even those which are not being continually upgraded in terms of new capabilities and code generation quality. When you try, as we do, to provide new, sophisticated, state of the art optimization and code generation capabilities in each version, you will occasionally get some, possibly ugly, problems, no matter how long and how thoroughly you test. But for each person who runs up against one of these problems, there are thousands who have had little or no trouble. They simply do not get on the net to tell everyone. Finally we would like to say that we are committed to producing high quality, high performance products and to fixing all problems reported to us in a timely fashion. Thanks for your continued support and interest - it really helps us develop better products. Dave Weil Project Mgr. Microsoft C Compiler Mark Roberts Mgr Compiler Technology Group
tneff@atpal.UUCP (Tom Neff) (05/18/88)
In article <1466@microsoft.UUCP> markro@microsof (Mark Roberts) writes: >We would like to address some of the questions raised by these and similar >recent articles appearing on the net. > (info on MSC origins + nice P.R. boilerplate omitted) > >... Some examples of Microsoft products built exclusively with C 5.0 >and/or C 5.1 (some with the addition of some MASM code) include: > > MS C, QuickC and FORTRAN compilers > QuickBasic 4.0 and Bascom compilers > CodeView Debugger > Utilities (Linker, Librarian, M editor, etc.) > XENIX (...et cetera, all OS's and compilers) > Applications (Project, XENIX Word, XENIX Multiplan) > >... (The >Applications group does have their own C compiler, but this was motivated >by the need for P-code generation to save space and to add 68K support, not ^^^^^^^^^^^^^ >because of any problems with the retail version.) ... There is something disturbing about this litany. Do we have the classic syndrome of the compiler writers creating a product only a compiler writer could love? Here in the real world we are applications developers too. Why shouldn't we believe we'd be better served if we got to use what your own Applications group uses, "to save space" etc. It strikes me as somewhat telling that XENIX WORD, which of course is free to use as much RAM as the user can afford to buy, uses MSC "native," while MS-DOS WORD -- substantially the same product but constrained to live within the realities of the predominant PC operating system's memory limits -- has to forgo MSC 5.x in favor of P-code. (This comes as no surprise to observant users who have noted WP.PGM et al. with interest for some time.) Now that you've decided to sell what you claim is MS's own "inhouse editor," which I must admit is pretty neat -- maybe it's to to sell your P-code "C" translator as well? -- Tom Neff UUCP: ...uunet!pwcmrd!skipnyc!atpal!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: are you kidding?
mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (05/18/88)
In <1466@microsoft.UUCP> markro@microsof (or uunet!microsof!markro) writes: >C 5.1 was not >released as a "bug fix" version for C 5.0, but rather as an OS/2 development >compiler. [...] C 5.1 does fix >a number of problems from C 5.0; however, Mr. Frost's statement implies that >these were problems of long standing, when in fact, the most serious problems >(with in-line intrinsics and loop optimizations) could not have existed >in previous versions of the compiler as these feature were added for C 5.0. >This is not to deny that there have been some bugs, even some serious ones, >in our compiler. It would be truly useful if Microsoft would do more than acknowledge that bugs exist. A list of known bugs in versions 4.0, 5.0, and 5.1 would save many of us countless hours trying to figure out whether our problems are caused by our programming errors or Microsoft's compiler bugs. >Finally we would like to say that we are committed to producing high quality, >high performance products and to fixing all problems reported to us in a >timely fashion. Fixing bugs in the next possible release is good. But making patches available when possible would be better. Sending out a bulk mailing to all registered owners of the compiler every two or three months, containing a list of known bugs and work-arounds would be a big help to all the smaller software developers who cannot afford to spend hours hunting through USENET or CompuServe postings in hope of resolving problems. The costs of doing this are minimal when compared to the major boost in goodwill it would generate. Nobody like to admit that a product has bugs. But to avoid telling people about them is wasting thousands of hours of programmer productivity world-wide in exchange for a little embarrassment. This is not an equitable trade-off. > Dave Weil > Project Mgr. > Microsoft C Compiler > > Mark Roberts > Mgr Compiler Technology Group Thank you for responding to the comments made in this forum. Even though your remarks were very general, it is importnat to know that you are paying attention. -- Mark D. Freeman (614) 262-1418 mdf@tut.cis.ohio-state.edu 2440 Medary Avenue ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!mdf Columbus, OH 43202-3014 Guest account at The Ohio State University
gudeman@arizona.edu (David Gudeman) (05/19/88)
In article <1466@microsoft.UUCP> markro@microsoft.UUCP (Mark Roberts) writes: >... >Finally we would like to say that we are committed to producing high quality, >high performance products and to fixing all problems reported to us in a >timely fashion. But you don't give the fixes to the people who have already bought the buggy software right? Most programmers are aware that it is impossible to get all bugs out of large software projects, and we would hardly fault Microsoft for that. But the issue you fail to address, and the one which will keep me from ever buying a Microsoft product, is the way you handle bug reports. When a software product (or any product for that matter) fails to meet specifications, the seller is morally (and often legally) obligated to correct the problem without charge. All I have heard about Microsoft indicates that they shaft their customers at every opportunity. Microsoft is not the only company that does this but that hardly serves as an excuse. And they can't even claim that they can't afford to fix bugs for free. The exorbitant rates they charge for their software would easily support periodic updates.
tat00@amdahl.uts.amdahl.com (Tom Thackrey) (05/20/88)
In article <5537@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >In article <1466@microsoft.UUCP> markro@microsoft.UUCP (Mark Roberts) writes: >>.. MS stuff deleted ... > >But you don't give the fixes to the people who have already bought the >buggy software right? ...stuff deleted ... >.... When a software product >(or any product for that matter) fails to meet specifications, the >seller is morally (and often legally) obligated to correct the problem >without charge. ... more stuff deleted ... I find myself in the unexpected position of defending Microsoft. I have a pile of MS products (MS-DOS, C, QBasic, Mouse, Windows, Windows SDK ...). As with any products there are problems from time to time. I have phoned, written, FedEx'd and sent net mail. I have had to talk to several people, wait, try again etc. On occasion I have had to upgrade my software to get a fix. However, when I needed a new printer driver for MS-Word, I was given the name of a local dealer who GAVE me 4 disks full of printer and display drivers. When I complained by mail of a QuickBasic bug which turned out to be covered in the READ.ME file, I got a phone call within a week explaining my error to me and asking me to call back if their diagnosis proved inaccurate. When I started working with Windows, MS had setup a Windows forum on GEnie for those of us who didn't want to pay for DIAL (MS tech support BBS). They also have uploaded a bunch of fixes and sample software to GEnie and several of their employees are regulars on the system. When I buy an update, I notice that the total price I pay is the same if I get or skip the minor updates (e.g. $75 for 2.0-3.0, $25 for 2.0-2.1 and $50 for 2.1-3.0). I am not under the illusion that MS products or support are perfect, but, they aren't significantly worse than most of the industry and they are better than some. Their major offense seems to be that they are big and successful. FLAME ON -- As far as moral obligation goes, I suggest you buy the product before you scream about poor support. -- Tom Thackrey tat00@amdahl.uts.amdahl.com <=> amdahl!tat00 [ My opinions are only my own. ]
gudeman@arizona.edu (David Gudeman) (05/21/88)
In article <32505@amdahl.uts.amdahl.com> tat00@amdahl.uts.amdahl.com (Tom Thackrey) writes: >In article <5537@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >><<an extremely calm and reasoned criticism of Microsoft customer >> support :-)>> > >I find myself in the unexpected position of defending Microsoft... >As with any products there are problems from time to time... Sure, I said I understand that. It's not the problems that bother me, it's the way the problems are handled. >...When I complained by mail of a QuickBasic bug which >turned out to be covered in the READ.ME file, I got a phone call within >a week explaining my error to me and asking me to call back if their >diagnosis proved inaccurate... This is defending MS? It takes them a week to answer a question, and then all they say is "Yup. That's a bug all right." >I am not under the illusion that MS products or support are perfect, >but, they aren't significantly worse than most of the industry and >they are better than some. As I said before, that's no excuse. >Their major offense seems to be that they are big and successful... What's wrong with being big and successful? That _is_ the goal of forming a company isn't it? No, Microsoft's major offense seems to be that they screw their customers. I can think of many big and successful companies I would gladly do business with. >FLAME ON -- As far as moral obligation goes, I suggest you buy the >product before you scream about poor support. Good grief (said in a dry monotone to avoid further charges of screaming :-). I said the reason I _don't_ buy it is because of the poor support (add a trace of sarcasm). Also, the term "scream" is an extremely poor choice (entering a dry, pedantic tone of voice). I assure you that I wrote the article in complete calm, and that I feel no particular passion or resentment towards Microsoft. Happily, I heard enough about them before I bought any of their products (except MSDOS, and I knew what I was getting into there). In fact, the reason I wrote the article was because it appeared that someone from MS actually reads these things, and I was hoping for a reply along the lines of "Gee, your right, we are going to completely change our customer support." (OK, it was a harmless fantasy.) David Gudeman gudeman@arizona.edu Department of Computer Science {allegra,cmcl2,ihnp4,noao}!arizona!gudeman The University of Arizona 602-621-2858 Tucson, AZ 85721
madd@bu-cs.BU.EDU (Jim Frost) (05/23/88)
In article <1466@microsoft.UUCP> markro@microsof (or uunet!microsof!markro) writes: |We would like to address some of the questions raised by these and similar |recent articles appearing on the net. [...] |Mr. Frost states that C 5.1 is at least the 6th release of MS C. In fact |C 5.1 is the 4th release of this compiler. I thank you for correcting me and for the additional information about the history of your compiler. |Finally we would like to say that we are committed to producing high quality, |high performance products and to fixing all problems reported to us in a |timely fashion. I'm sorry, but I just can't believe this. Those people I've met who are doing serious development with several of your packages tell me that your technical support is almost never timely. In one case, a bug in the Fortran compiler (4.0) relating to use of the 8087 was reported by a friend of mine. Tech support stated (after something like an hour on hold) that it must be because he was using a clone. He then tried using true blue, same problem. Tech support called back *two weeks* later to inform him that they'd found the problem, it was a bug, and it would be fixed in a later version of the compiler. No immediate bug fix or indication of just how long it will be until the "later version". I sure hope no one was trying to number crunch with that version of MS Fortran. How timely *are* your bug fixes? Compare your response time with that of Borland. They had several (pretty severe) problems with their initial release of Turbo C. Within a week or so of hearing about the bugs, there were patches to fix them. Within a couple of months they had a new release of the compiler with the bugs fixed (and lots of enhancements to boot). Now, you've known that there was a serious problem with loop optimization in MS C 5.1 for quite some time. It's serious enough that the recent Byte review stated that "loop optimization generated invalid results" -- it showed up even in simple benchmarks. *Where is the bug fix*? Perhaps Microsoft and I have differing opinions of "timely." "High quality, high performance products". Ok, I'll admit that many of your products (MS Word, Windows, Excel) are very nice. Your very own C compiler comes to mind as a counterexample. Why do you think it is that people flame about your C compiler? Because it doesn't work as it's supposed to. Worse, it doesn't even work as it's *advertised* to. This is "high quality"? Not in my book. The people who I speak to that *must* use your product ("industry standard" and all) aren't happy about it. If you think I'm wrong, talk to sam@vax.ftp.com, who you flamed in your message. Or the people who (just a few short months ago) were discussing the possibility of a class-action suit against Microsoft regarding MS C. "High performance"? Your C compiler is nicer than most *as a package*. The nicest thing about it is Codeview; nobody else has that. The code generated by your compiler is mediocre compared to several other compilers on the market; lucky for you that their libraries aren't quite up to par with yours. Many compilers produce either smaller or faster code (although few do both, and even fewer have nice libraries). The compilation speed of your compiler is horrendous; few other compilers are so slow. I don't think I'd call your compiler high performance; it is probably the weakest part of the entire development package. I'm sorry I don't share your point of view with regards to your C compiler, but as a programmer I'd rather use a programming package without all the bells and whistles if it *works*. Libraries can be written. Debugging can be done without a fancy debugger. But writing a program with a broken compiler is a serious problem. | Dave Weil | Project Mgr. | Microsoft C Compiler jim frost madd@bu-it.bu.edu
dave@micropen (David F. Carlson) (05/24/88)
In article <22790@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes: > In article <1466@microsoft.UUCP> markro@microsof (or uunet!microsof!markro) writes: > |We would like to address some of the questions raised by these and similar > |recent articles appearing on the net. > |Finally we would like to say that we are committed to producing high quality, > |high performance products and to fixing all problems reported to us in a > |timely fashion. > | Dave Weil > | Project Mgr. > | Microsoft C Compiler Having been in a project where we were to use MSC 4.0 and having manifest compiler/linking problems and contortions, we decided to bag DOS and develop under UNIX to save ourselves a double pain: poor MSC and poor DOS. If someone were to fence me in on when should I (we) start OS/2 development, my answer would be whenever a Borland (or other quality third party) C compiler is available to get the job done! MSC: never again! -- David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll