cliffhanger@cup.portal.com (Cliff C Heyer) (08/31/89)
Wondered if it's advisable to develop MS DOS applications (in C) using UNIX rather than MSDOS.(assuming 386, 6+MB, etc) It seems multitasking, etc., would be of help to increase productivity... any comments greatly appreciated! Cliff C Heyer
fredex@cg-atla.UUCP (Fred Smith) (08/31/89)
In article <21714@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >Wondered if it's advisable to develop >MS DOS applications (in C) using UNIX >rather than MSDOS.(assuming 386, 6+MB, etc) >It seems multitasking, etc., would be of >help to increase productivity... > >any comments greatly appreciated! > > > >Cliff C Heyer I have seen ads in (Dr. Dobbs, Byte, C User's Journal--one of them I don't recall which) from a company which claims to have the entire Microsoft C package available on Unix for cross-development of DOS software. Sorry I don't remember the company, but if you dig thru the past year of those 3 mags you will see it! Fred
plb@cbnewsi.ATT.COM (peter.l.berghold) (08/31/89)
From article <21714@cup.portal.com>, by cliffhanger@cup.portal.com (Cliff C Heyer): > Wondered if it's advisable to develop > MS DOS applications (in C) using UNIX > rather than MSDOS.(assuming 386, 6+MB, etc) > It seems multitasking, etc., would be of > help to increase productivity... Cliff, I do this sort of thing all the time. Since I want to be able to use UNIX's SCCS stuff, etc. as well as share code with folks I prefer to. I still, however, have to download all the sources to the PC and compile it there as I don't have any cross compilers for MSDOS. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | _ /| || Peter L. Berghold, AT&T, HRSAG, UUCP: att!violin!plb | | \`o_O' ||============================================================ | | ( ) || Disclaimer: If you find an opinion in this posting somewhere| | U || it is no doubt mine, and not my employers. I'm the only | | Aachk! || person crazy enough to take this stand! | | Phft! || | VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
jbudet@oakhill.UUCP (Jim Budet) (09/01/89)
fredex@cg-atla.UUCP (Fred Smith) writes: >> >>Cliff C Heyer >I have seen ads in (Dr. Dobbs, Byte, C User's Journal--one of them I >don't recall which) from a company which claims to have the entire >Microsoft C package available on Unix for cross-development of DOS >software. >Sorry I don't remember the company, but if you dig thru the past year >of those 3 mags you will see it! >Fred Another possibility is to use a product called SoftPC from a company of the same name (I think). SoftPC is a IBM XT emulator that runs on various 68000 based machines. I have seen ads for MacIntosh and Sun hosted systems. With it, you could use cross compilers or PC compilers running under SoftPC and then test the program on SoftPC. I am sure that there are some restrictions in the emulation capabilities. =============================================================================== Jim Budet Usenet: oakhill!jbudet@cs.utexas.edu Motorola Microprocessor Products Group Compuserve: 73177,171 Austin, Texas Phone: (512) 891-3175 ------------------------------------------------------------------------------- Motorola does not necessarily share the opinions expressed in this message. ===============================================================================
ked@garnet.berkeley.edu (Earl H. Kinmonth) (09/01/89)
In article <7582@cg-atla.UUCP> fredex@cg-atla.UUCP (Fred Smith) writes: >In article <21714@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: > >I have seen ads in (Dr. Dobbs, Byte, C User's Journal--one of them I >don't recall which) from a company which claims to have the entire >Microsoft C package available on Unix for cross-development of DOS >software. The C compiler that comes with the SCO Xenix development package is basically Microsoft C and is capable, while running under Xenix, of producing either Xenix or MSDOS executables, depending on which libraries are linked and which loader is used for the linking. Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
fyl@fylz.UUCP (Phil Hughes) (09/01/89)
In article <683@cbnewsi.ATT.COM>, plb@cbnewsi.ATT.COM (peter.l.berghold) writes: > From article <21714@cup.portal.com>, by cliffhanger@cup.portal.com (Cliff C Heyer): > > Wondered if it's advisable to develop > > MS DOS applications (in C) using UNIX > I do this sort of thing all the time. Since I want to be able to > use UNIX's SCCS stuff, etc. as well as share code with folks I prefer to. > I still, however, have to download all the sources to the PC and compile it > there as I don't have any cross compilers for MSDOS. I have been doing the same thing. The UNIX tools sure make a difference. I can't imagine having to do development under DOS. I have been doing development under system V on a UNIX system, using sdb for debugging and then, once things seem ok, just writing the stuff out to floppy and loading and compiling under DOS. I have been using Turbo C 1.5 and have had virtually no portability problems. The only mistake I made was to talk to the DOS screen instead of using curses. I now have to do a re-write to port the program to another system. -- Phil Hughes -- FYL -- 8315 Lk City Wy NE -- Suite 207 -- Seattle, WA 98115 {amc-gw,uunet!pilchuck}!ssc!fylz!fyl
rmarks@KSP.Unisys.COM (Richard Marks) (09/01/89)
In article <21714@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >Wondered if it's advisable to develop >MS DOS applications (in C) using UNIX >rather than MSDOS.(assuming 386, 6+MB, etc) >It seems multitasking, etc., would be of >help to increase productivity... I think that the interactive debugging capabilities available under TurboC are an order or magnitude superior to what is on Unix. In fact I develop on MS-DOS and then port to Unix. Richard Marks rmarks@KSP.unisys.COM
alanr@tekigm2.MEN.TEK.COM (Alan Rovner) (09/01/89)
Here at Tek, we develop PC code on our Gould Unix mainframe using the Oasys Cross Development package. It includes Microsoft C 5.1, MASM 5.1, the linker and librarian. They work fine, no problem. The only funny thing is you need to be real careful about path names/option switches in Unix. All option switches are specified using - instead of / which Unix interprets as path names. What Oasys did is to obtain the actual source code from Microsoft and simply recompile it under different platforms. You even get all the normal and standard Microsoft copyright messages. One thing though, it ain't cheap. I believe the whole thing ran $30,000 for three mainframes to run the stuff. So unless you're contemplating serious PC development, you might look at something else. Regards, Al Rovner
uri@arnor.UUCP (Uri Blumenthal) (09/01/89)
...................................
[ lots of stuff ]
...................................
Sorry, guys, but what's wrong with developing the software for
MS DOS under UNIX, and then test it on the very same computer
and UNIX under VP/ix (or DOS Merge)? The emulation seems 99%
perfect, and for commercial applications it should be more than
enough... You can install Microsoft C under VP/ix...
-----------------
<Disclaimer>desnoyer@apple.com (Peter Desnoyers) (09/02/89)
In article <21714@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: > Wondered if it's advisable to develop > MS DOS applications (in C) using UNIX > rather than MSDOS.(assuming 386, 6+MB, etc) > It seems multitasking, etc., would be of > help to increase productivity... > any comments greatly appreciated! > Cliff C Heyer In my mind the best development environment for MSDOS (or other micros - for instance Macintoshes) would be a cross-compiler running on a fair-sized UNIX system, such as a big Sun or a VAX. Pluses: + UNIX tools - sccs, make, awk, all those other fun things. + (this is the big one) - you can put all the source - or at least the current master version - in one place instead of having it scattered across twice as many micros as you have programmers, half of them turned off and not accessible from the net at any given time. + the concept of developing on a machine that can crash in the middle of running a make - or worse yet, while you are editing - is abhorrent. + and, finally, you're not trying to run some horribly buggy piece of software on the machine that your latest, not-quite-backed-up-yet copy of the source is resident on. After all, rest assured that in MS-DOS your disk controller is just another unprotected address for your stray pointers to search for. If you only have one programmer, most of the advantages of the UNIX cross-development environment go away. Especially if the machine running UNIX is a PC clone. The UNIX tools are useful in any case, however. Peter Desnoyers Apple ATG (408) 974-4469
bruce@tolerant.UUCP (Bruce Hochuli) (09/02/89)
In article <578@fylz.UUCP: fyl@fylz.UUCP (Phil Hughes) writes: :In article <683@cbnewsi.ATT.COM>, plb@cbnewsi.ATT.COM (peter.l.berghold) writes: :> From article <21714@cup.portal.com>, by cliffhanger@cup.portal.com (Cliff C Heyer): :> > Wondered if it's advisable to develop :> > MS DOS applications (in C) using UNIX : :> I do this sort of thing all the time. Since I want to be able to :> use UNIX's SCCS stuff, etc. as well as share code with folks I prefer to. :> I still, however, have to download all the sources to the PC and compile it :> there as I don't have any cross compilers for MSDOS. : :I have been doing the same thing. :The UNIX tools sure make a difference. I can't imagine having :to do development under DOS. I have been doing development under :system V on a UNIX system, using sdb for debugging and then, once :things seem ok, just writing the stuff out to floppy and loading :and compiling under DOS. I have been using Turbo C 1.5 and have :had virtually no portability problems. I used to have the same philosophy for development and sould still use it today for certain circumstances. The last major development environment that I set up was for 12 386 clones running Xenix with the mandate to cross development for DOS and Xenix. Worked fine. All you have to do to cross- develop is to set the DOS flag for the compiler and the linker. For smaller developments or in situations where multitasking is not a big win, I will pick DOS every time even though, I too, love the UNIX tools. 1.) You can buy all of the UNIX tools for DOS cheaply. I have the Polyshell stuff and it works great. They, and other, can supply SCCS, AWK, and all of the normal stuff you find on UNIX. 2.) The debuggers available under DOS are a ton better. 3.) Nroff/Troff sucks. It is a pain to switch environments for documentation. 4.) There is a lot more software in general that is available for the DOS world to make life easier. 5.) Compatability gets weird when dealing with Xenix. Some pieces of hardware and lots of networking schemes just don't work without heroics. If you just HAVE to have multitasking, you can experiment with DOS in a Xenix window and see if this works for you.
cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (09/02/89)
In article <4009@internal.Apple.COM> desnoyer@apple.com (Peter Desnoyers) writes: >If you only have one programmer, most of the advantages of the UNIX >cross-development environment go away. Especially if the machine running >UNIX is a PC clone. The UNIX tools are useful in any case, however. And are *all* available under the MKS Toolkit. I'd imagine that for individual work a 386 w/MKS would be a very satisfactory development environment. Just a pleased as punch MKS proponent. . . -- O----------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large | Systems Science, SUNY Binghamton, cjoslyn@bingvaxu.cc.binghamton.edu V All the world is biscuit shaped. . .
palowoda@fiver.UUCP (Bob Palowoda) (09/02/89)
From article <21714@cup.portal.com>, by cliffhanger@cup.portal.com (Cliff C Heyer): > Wondered if it's advisable to develop > MS DOS applications (in C) using UNIX > rather than MSDOS.(assuming 386, 6+MB, etc) > It seems multitasking, etc., would be of > help to increase productivity... > > any comments greatly appreciated! I use a 386 UNIX with Simul-Task and Turbo-C 2.0. What I found out is I can compile a UNIX and a DOS program from the same source simultanous. From the same souce file. Of coarse the the proper ifdefs. The only thing you would have to watch out for is someone working on the same source file while running dos. Another thing that could be helpfull is running several Turbo-C's each working on different modules of a program. You can use the unix source control system to manage the release. Save's file space I guess. Your right you need around 6meg+. I'm running 6.8 meg and haven't had any problems at all. Even with two people logged into the bbs and me running a couple TC compiles it continues to run smoothly. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Home {sun,dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun,pyramid,decwrl}!megatest!palowoda (415)-623-8806 1200/2400/9600/19200 Voice: (415)-623-7495 Public access UNIX system
palowoda@fiver.UUCP (Bob Palowoda) (09/04/89)
From article <2396@bingvaxu.cc.binghamton.edu>, by cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn): > In article <4009@internal.Apple.COM> desnoyer@apple.com (Peter Desnoyers) writes: >>If you only have one programmer, most of the advantages of the UNIX >>cross-development environment go away. Especially if the machine running >>UNIX is a PC clone. The UNIX tools are useful in any case, however. > > And are *all* available under the MKS Toolkit. I'd imagine that for > individual work a 386 w/MKS would be a very satisfactory development > environment. > > Just a pleased as punch MKS proponent. . . All but multi-tasking. Yes I admit MKS has all the right tools. But if I remember correct the orig. poster wanted to know if multi-tasking increased program development. One thing I would like to see in the MKS package is multi-tasking. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Home {sun,dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun,pyramid,decwrl}!megatest!palowoda (415)-623-8806 1200/2400/9600/19200 Voice: (415)-623-7495 Public access UNIX system
dmt@mtunb.ATT.COM (Dave Tutelman) (09/04/89)
In article <4009@internal.Apple.COM> desnoyer@apple.com (Peter Desnoyers) writes: > >In my mind the best development environment for MSDOS (or other micros - >for instance Macintoshes) would be a cross-compiler running on a >fair-sized UNIX system, such as a big Sun or a VAX. How about a distributed MSDOS environment on a LAN, using a UNIX-based file-server, such as AT&T's StarGROUP servers. I've lived in such an environment, and can assure you that it works. >Pluses: > >+ UNIX tools - sccs, make, awk, all those other fun things. There are MAKE and AWK clones available for MSDOS. Polytron makes an RCS-like source control system for DOS, that includes working from shared files on a file server. And, if the server is itself a UNIX box, you can run the UNIX utilities remotely if you don't like the DOS versions of the utilities. For instance, you could have MSDOS scripts that remotely invoke SCCS on the server machine. >+ (this is the big one) - you can put all the source - or at least the >current master version - in one place instead of having it scattered >across twice as many micros as you have programmers, half of them turned >off and not accessible from the net at any given time. Precisely! And you get the same advantage from a LAN-based solution with the files on a server. >+ the concept of developing on a machine that can crash in the middle of >running a make - or worse yet, while you are editing - is abhorrent. My experience is that my UNIX environment crashes significantly more often than my DOS environment. Most (but not all) the time its the access line rather than the UNIX system itself, but the deffect on my work is the same. I'd rather do my stuff from a single machine that's right there. And if I'm doing a make from the server, the partial products of the make don't get lost. >+ and, finally, you're not trying to run some horribly buggy piece of >software on the machine that your latest, not-quite-backed-up-yet copy of >the source is resident on. After all, rest assured that in MS-DOS your >disk controller is just another unprotected address for your stray >pointers to search for. True enough, but access to the file server is much less chancy. Things have to be sane enough to be run the file access protocol correctly, in order to screw up the source accidentally. UNIX is an excellent development environment. But we are talking here SPECIFICALLY about developing software to run under MSDOS. The LAN-based approach allows us to use the DOS-optimized development tools that Borland, Microsoft, and others provide. It also allows us to use the UNIX tools when they are more appropriate. I am biased. I work at AT&T, in the organization that develops the StarGROUP products. But I'm also experienced; we use our products in our process, and have had successful results. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Middletown, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 957 6583 | +---------------------------------------------------------------+
larry@nstar.UUCP (Larry Snyder) (09/04/89)
In article <1989Sep1.024752.25597@agate.uucp>, ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: > The C compiler that comes with the SCO Xenix development package is > basically Microsoft C and is capable, while running under Xenix, of > producing either Xenix or MSDOS executables, depending on which > libraries are linked and which loader is used for the linking. Earl - is SCO shipping their complier as well as the AT&T compiler with their Unix System V product? -- Larry Snyder uucp:iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site, Notre Dame, IN USA
larry@nstar.UUCP (Larry Snyder) (09/04/89)
In article <389@arnor.UUCP>, uri@arnor.UUCP (Uri Blumenthal) writes: > Sorry, guys, but what's wrong with developing the software for > MS DOS under UNIX, and then test it on the very same computer > and UNIX under VP/ix (or DOS Merge)? The emulation seems 99% > perfect, and for commercial applications it should be more than > enough... You can install Microsoft C under VP/ix... I have been playing with Turbo C under VP/ix which appears to run fine - even when working with communications applications which need to access the serial ports. -- Larry Snyder uucp:iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site, Notre Dame, IN USA
rcw@scicom.AlphaCDC.COM (Robert White) (09/04/89)
In article <389@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes:
#
#Sorry, guys, but what's wrong with developing the software for
#MS DOS under UNIX, and then test it on the very same computer
#and UNIX under VP/ix (or DOS Merge)? The emulation seems 99%
#perfect, and for commercial applications it should be more than
#enough... You can install Microsoft C under VP/ix...
#-----------------
You said it, 99% perfect. A 1% return on a product for hardware
incompatibility reasons will destroy that product's reputation.
We develop under Unix, but have found out that products must be
tested in their destination environment, at least as the technology
stands now.terry@tah386.manhattan.ks.us (Terry Hull) (09/04/89)
In article <29@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >Earl - is SCO shipping their complier as well as the AT&T >compiler with their Unix System V product? Well, I'm not Earl, but I do know that when the SCO UNIX 3.2 development system starts shipping it will include both the MSC compiler and the AT&T compiler. I, for one am anxiously awaiting the ability to use MSC (with CodeView), PCC, or GCC as the need arises. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
palowoda@fiver.UUCP (Bob Palowoda) (09/05/89)
From article <1649@mtunb.ATT.COM>, by dmt@mtunb.ATT.COM (Dave Tutelman): > In article <4009@internal.Apple.COM> desnoyer@apple.com (Peter Desnoyers) writes: [some stuff deleted] >>+ the concept of developing on a machine that can crash in the middle of >>running a make - or worse yet, while you are editing - is abhorrent. > My experience is that my UNIX environment crashes significantly > more often than my DOS environment. Most (but not all) the time > its the access line rather than the UNIX system itself, but the > deffect on my work is the same. I'd rather do my stuff from a > single machine that's right there. And if I'm doing a make from > the server, the partial products of the make don't get lost. Wait a second here. I my experience it's DOS that crashes more often. In fact that's on of the main reason why I started to work under unix because I got sick and tired of locking up a dos machine which brought down the whole machine. If the majority of the time is locking up the file server under a lan don't you think the lan software protection should be improved to prevent this? One may ask are you writeing software that locks up the line. In anycase I have locked up the line while debugging some dos software under unix. Big deal I just kill the processes off and log back in and figure out what went wrong to cause it to crash. I didn't loose anything when it happened, nor did it affect other users that where doing something else on the system. >>+ and, finally, you're not trying to run some horribly buggy piece of >>software on the machine that your latest, not-quite-backed-up-yet copy of >>the source is resident on. After all, rest assured that in MS-DOS your >>disk controller is just another unprotected address for your stray >>pointers to search for. > True enough, but access to the file server is much less chancy. > Things have to be sane enough to be run the file access protocol > correctly, in order to screw up the source accidentally. Once again it appears that your showing a problem in the lan software protection. While I would not disagree that dos software writes to address that it shouldn't, a unix lan should offer some protection against it. But in all fairness it's much better than say something like Novell which dos software can bring down the whole system. I've seen that happen too many times. Alot of these buggy pointers as you point out are produced by the compiliers under dos. One must wonder if it's a virus or some software that bashed the harddisk. Running under ATT's Simul-Task does have it's advantages here. When a certain piece of buggie dos software if it trys to write out of it's address it produces a segmentation fault which at least can be recovered from. I'd like to hear of cases where a dos program totally locked up the unix system, what instructions that caused it? And if there is anyway to detect it before it happens. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Home {sun,dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun,pyramid,decwrl}!megatest!palowoda (415)-623-8806 1200/2400/9600/19200 Voice: (415)-623-7495 Public access UNIX system
les@chinet.chi.il.us (Leslie Mikesell) (09/05/89)
In article <1649@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes: [Re: Lan access to source files] > My experience is that my UNIX environment crashes significantly > more often than my DOS environment. Most (but not all) the time > its the access line rather than the UNIX system itself, but the > deffect on my work is the same. That's hardly going to be a problem running VP/ix from the console. >UNIX is an excellent development environment. But we are talking here >SPECIFICALLY about developing software to run under MSDOS. The LAN-based >approach allows us to use the DOS-optimized development tools that >Borland, Microsoft, and others provide. It also allows us to use >the UNIX tools when they are more appropriate. I agree that this approach does work well, but it is more appropriate for an environment with several users. Vp/ix can give the same effect to a single user at the console plus the advantage of the multiple virtual consoles. Serial line access is available for non-graphic programs dos programs and they can be run from shell scripts. >I am biased. I work at AT&T, in the organization that develops the >StarGROUP products. But I'm also experienced; we use our products >in our process, and have had successful results. The VP/ix and DOS SERVER programs can compliment each other, but you really should get together and agree on a netbios interface so that file and record locking, releasing print jobs, etc. would work properly when both methods are used to access files on the same server. Les Mikesell
bruce@tolerant.UUCP (Bruce Hochuli) (09/06/89)
In article <563@tah386.manhattan.ks.us> terry@tah386.manhattan.ks.us (Terry Hull) writes: >AT&T compiler. I, for one am anxiously awaiting the ability to use >MSC (with CodeView), PCC, or GCC as the need arises. > Are they really going to include Codeview? This is one of my annoyances with the SCO products. I used to use XENIX 2.2 and got totally burned out with thos awful debuggers. Used (shudder) a lot of printfs.
palowoda@megatest.UUCP (Bob Palowoda) (09/06/89)
From article <1875@scicom.AlphaCDC.COM>, by rcw@scicom.AlphaCDC.COM (Robert White): > In article <389@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: > # > #Sorry, guys, but what's wrong with developing the software for > #MS DOS under UNIX, and then test it on the very same computer > #and UNIX under VP/ix (or DOS Merge)? The emulation seems 99% > #perfect, and for commercial applications it should be more than > #enough... You can install Microsoft C under VP/ix... > #----------------- > > You said it, 99% perfect. A 1% return on a product for hardware > incompatibility reasons will destroy that product's reputation. > We develop under Unix, but have found out that products must be > tested in their destination environment, at least as the technology > stands now. I don't understand what you mean. All your products work on 100% of the machines. If so I'm suprise. Their are cases where the customer just dosn't want you to test on their equiptment. Some of them beleive if you can't deliver something working you have a bad reputation already. Me, I have yet to see a product that dosn't have a flaw in it. Technology will never be perfect. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun}ys2!fiver!palowoda (A XBBS System) 2-lines BBS: (415)623-8809 2400/1200 (415)623-8806 1200/2400/9600/19200
palowoda@megatest.UUCP (Bob Palowoda) (09/06/89)
From article <5804@tolerant.UUCP>, by bruce@tolerant.UUCP (Bruce Hochuli): > In article <563@tah386.manhattan.ks.us> terry@tah386.manhattan.ks.us (Terry Hull) writes: >>AT&T compiler. I, for one am anxiously awaiting the ability to use >>MSC (with CodeView), PCC, or GCC as the need arises. >> > Are they really going to include Codeview? This is one of my > annoyances with the SCO products. I used to use XENIX 2.2 > and got totally burned out with thos awful debuggers. Used > (shudder) a lot of printfs. Yes I will be interesting to see how it works with system calls. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun}ys2!fiver!palowoda (A XBBS System) 2-lines BBS: (415)623-8809 2400/1200 (415)623-8806 1200/2400/9600/19200
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/06/89)
In article <5804@tolerant.UUCP>, bruce@tolerant.UUCP (Bruce Hochuli) writes: | Are they really going to include Codeview? This is one of my | annoyances with the SCO products. I used to use XENIX 2.2 | and got totally burned out with thos awful debuggers. Used | (shudder) a lot of printfs. The info I have indicates that Codeview is included and works under UNIX. More info when I get the product. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon