jshekhel@feds19.prime.com (Jerry Shekhel ) (07/03/90)
Hello. Does anyone know whether Borland C++ is capable of producing Windows 3.0 applications if used with the SDK? Also, can the Borland debugger, which supports hardware traps on the 386 be used to debug Windows programs? Please reply with a follow-up. Mail doesn't seem to be able to reach these parts of the world. Thanks in advance. -- JJS
dsampson@x102a.harris-atd.com (sampson david 58163) (07/05/90)
In article <604@cvbnetPrime.COM> jshekhel@feds19.prime.com (Jerry Shekhel ) writes: >Does anyone know whether Borland C++ is capable of producing Windows >3.0 applications if used with the SDK? Also, can the Borland >debugger, which supports hardware traps on the 386 be used to debug >Windows programs? The current version of Turbo C++ does not allow you to use the SDK to write windows 3.0 programs. Somebody please tell me I wrong :). I see nothing in the current documentation that specifically states that you can link to the SDK libs and use Link4 [the SDK supplied linker] to produce windows compatable programs. While Borland has made press statements that they were going to support that environment, we'll all have to wait for the next release of C++ to do that. The intresting thing about all of this is that Borland began shipping Turbo C++ the week before Microsoft put on the big blitz show for Windows 3.0. I read in PC Week that Borland was one of the vendors at the show and that they were demonstrating the next version of Turbo C++ that ran under windows (editor and all) and it produced Windows 3.0 compatable code. Since Borland is very busy selling the current version of C++, I'd expect them to sit on this next release until late fall (Nov - Dec) at the earlist before announcing the product they demonstrated at the MS Windows show. After all, why should they sabatoge sales of their own product. Of course, they could create "parallel" C++ products: windows and non windows versions. But they haven't said anything publicly yet other than they will support the windows environment. Personally, I'm anxiously awaiting the Borland product. I really don't like the MS C environment for developing applications. The MS C compiler is very powerful, but I have run into problems. I have the SDK for windows 2.xx. To run Codeview, you must install an expanded memory driver. So I installed the driver that was shipped with my Gateway 2000 20MHz 386. Once that was loaded, Windows 3.0 wouldn't fire up. I got a message box that saying that another driver was conflicting with the memory that windows wants to use, blah, blah, blah..... So I unloaded the expanded memory driver and tried to run Codeview as a window in 386 mode, figuring that windows is so smart now, it will manage the memory for me :). Well Codeview complained that it needs an expanded memory driver before it can load. Catch 22. So now I have to put print statements in the code to see what's happening, which is almost useless as a debugging aid. I ordered the SDK for windows 3.0. Man, I hope this hassle goes away!! You can appreciate why I am prejudiced in a positive way towards Borlands environment. Part 2 of your question about the debugger, I'll claim ignorance on. I've never tried playing around with it in that fashion. I will say that unlike Codeview, Borland's debugger is highly intutive. I've had various versions ever since it came out about 2 years ago (I've upgraded each time). I still haven't had to read the manual yet to do the things I wanted to do. Now that's a well designed, user friendly program! David -- ------------------------------------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/06/90)
dsampson@x102a.harris-atd.com (sampson david 58163) writes: >While Borland has made press statements that they were going to >support that environment, we'll all have to wait for the next release >of C++ to do that. Have you tried Zortech C++? It can produce Windows compatible code. >I have the SDK for windows 2.xx. To run Codeview, you must install an >expanded memory driver. So I installed the driver that was shipped >with my Gateway 2000 20MHz 386. Once that was loaded, Windows 3.0 >wouldn't fire up. I got a message box that saying that another driver >was conflicting with the memory that windows wants to use, blah, blah, >blah..... So I unloaded the expanded memory driver and tried to run >Codeview as a window in 386 mode, figuring that windows is so smart >now, it will manage the memory for me :). Well Codeview complained >that it needs an expanded memory driver before it can load. Catch 22. >So now I have to put print statements in the code to see what's >happening, which is almost useless as a debugging aid. On your machine Windows 3 should emulate expanded memory, if you start an old application. I have so far produced a few thousand lines of Windows code only, and may haven't fallen into all the traps which are there, yet. But I am quite proud that I have never touched the Codeview debuggger (or any other interactive debugger) while creating Windows applications. I am a bit cheating here. I use a very fine and free set of debugging macros which where written by Fred Fish. These macros produce a nice subroutine call tree. You can add debugging output statements tagged with keywords and enable them separatly. All the output code is disabled by default, but sits there until you need it. You can remove all code by one aditional #define. All the output goes to a file and can be analyzed after the program has terminated. I prefer this over the creation of a debugging output window, because it doesn't interfere with Windows in any way. I added decoding the message identifier of window functions and printing it in symbolic form. Wolfgang Strobl #include <std.disclaimer.hpp>
dsampson@x102a.harris-atd.com (sampson david 58163) (07/06/90)
In article <3046@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >I am a bit cheating here. I use a very fine and free set of debugging >macros which where written by Fred Fish. I haven't seen these. I'd like to look it over. Where are they available and what's the arc or zip file name? -- ------------------------------------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/07/90)
dsampson@x102a.harris-atd.com (sampson david 58163) writes: >In article <3046@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) >writes: >>I am a bit cheating here. I use a very fine and free set of debugging >>macros which where written by Fred Fish. >I haven't seen these. I'd like to look it over. Where are they >available and what's the arc or zip file name? The version I use came from as a posting here on usenet, two or three years ago. I know that the package is available on one of the Fish disks (this is a well known collection of PD software disks for the Amiga, maintained by Fred Fish). Look for something containing the string "DBUG". Wolfgang Strobl #include <std.disclaimer.hpp>
ted@grebyn.com (Ted Holden) (07/11/90)
In article <DSAMPSON.90Jul5094845@x102a.harris-atd.com> dsampson@x102a.harris-atd.com (sampson david 58163) writes: >In article <604@cvbnetPrime.COM> jshekhel@feds19.prime.com (Jerry >Shekhel ) writes: > >>Does anyone know whether Borland C++ is capable of producing Windows >>3.0 applications if used with the SDK? Also, can the Borland >>debugger, which supports hardware traps on the 386 be used to debug >>Windows programs? > >The current version of Turbo C++ does not allow you to use the SDK to >write windows 3.0 programs. Somebody please tell me I wrong :). I With all due respect to Borland, and they're due a lot of respect, they're 3 years late and many dollars short on this one. Walter Bright, one of the very brightest lights in American computer science, took almost a whole year getting Zortech's first version of C++ out the door and another year getting all kinks out prior to the new Zortech 2.x releases which, incidentally, support Windows development. The best info available is that the front end of a C++ compiler is something like five times as complex as that for a C compiler, i.e. C++ is about as complex a language as anybody can do any kind of a reasonable job with in implementing (Ada, by contrast, is TOO complex to implement well). You have to figure that Zortech has a 2.5 - 4 year jump on both Borland and MicroSoft in C++ and that they might just maintain it. I wouldn't spend money on anybody elses C++ compiler for DOS/Windows/386-IX right now. Ted Holden HTE
SRWMRBD@windy.dsir.govt.nz (ROBERT) (07/13/90)
In article <20226@grebyn.com>, ted@grebyn.com (Ted Holden) writes: .......... > With all due respect to Borland, and they're due a lot of respect, > they're 3 years late and many dollars short on this one. Walter Bright, > one of the very brightest lights in American computer science, took > almost a whole year getting Zortech's first version of C++ out the door > and another year getting all kinks out prior to the new Zortech 2.x > releases which, incidentally, support Windows development. The best > info available is that the front end of a C++ compiler is something like > five times as complex as that for a C compiler, i.e. C++ is about as > complex a language as anybody can do any kind of a reasonable job with > in implementing (Ada, by contrast, is TOO complex to implement well). > > You have to figure that Zortech has a 2.5 - 4 year jump on both Borland > and MicroSoft in C++ and that they might just maintain it. I wouldn't > spend money on anybody elses C++ compiler for DOS/Windows/386-IX right > now. My guess is that Zortech's jump on Borland should be measured in months rather than years. Borland's C++ compiler is much much better than the early versions of Zortech. I'll try to post a brief review to the C++ newsgroup shortly. Robert
bill@polygen.uucp (Bill Poitras) (07/14/90)
In article <20226@grebyn.com> ted@grebyn.UUCP (Ted Holden) writes: >In article <DSAMPSON.90Jul5094845@x102a.harris-atd.com> dsampson@x102a.harris-atd.com (sampson david 58163) writes: >>In article <604@cvbnetPrime.COM> jshekhel@feds19.prime.com (Jerry >>Shekhel ) writes: >> >>>Does anyone know whether Borland C++ is capable of producing Windows >>>3.0 applications if used with the SDK? >> >>The current version of Turbo C++ does not allow you to use the SDK to >>write windows 3.0 programs. Somebody please tell me I wrong :). I The New Turbo Assembler that comes with Turbo C++ is capable of generating Windows compatible code. Turbo C 2.0 is cabable of generating assembler from C code, so that I assume that Turbo C++ can too. What that means is that you can generate assembler from the C(++) code, then assemble it into object code. The source of the information about the Turbo Assembler is a Turbo C++ pamphlet that I found in a computer software store. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | | bill@polygen.com | +-----------------+---------------------------+-----------------------------+