dmk8r@plaid.cs.Virginia.EDU (Darrell M. Kienzle) (02/15/91)
FYI, I just spoke to the people from Borland's Educational Sales Department, and was told that the price for C++ 2.0 was $99.95 through their program, postage paid. To order via this method, they require a letter from your school / faculty member on school letterhead "introducing" you as a registered student. Mail this with Credit Card info to: Borland International Educational Sales Department PO Box 660001 Scotts Valley, CA 95067-0001 Hope this helps, Darrell Kienzle dmk8r@Virginia.EDU
resnicks@netcom.COM (Steve Resnick) (02/16/91)
In article <1991Feb15.041246.15904@murdoch.acc.Virginia.EDU> dmk8r@plaid.cs.Virginia.EDU (Darrell M. Kienzle) writes: > >FYI, I just spoke to the people from Borland's Educational Sales >Department, and was told that the price for C++ 2.0 was $99.95 >through their program, postage paid. > I just got my upgrade coupon. If you own TC or TC++ the upgrade price is $149.95. If you own TC or TC++ Professional it's $99.95. It liss for $495.95 Thought you'd like to know ... Steve -- ------------------------------------------------------------------------------- resnicks@netcom.com, apple!camphq!105!steve.resnick, IFNA: 1:143/105.0, USNail: 530 Lawrence Expressway, Suite 374 Sunnyvale, Ca 94086 - In real life: Steve Resnick. Flames, grammar and spelling errors >/dev/null 0x2b |~ 0x2b, THAT is the question. The Asylum OS/2 BBS - (408)263-8017 12/2400,8,1 - Running Maximus CBCS 1.2 -------------------------------------------------------------------------------
cs161fhn@sdcc10.ucsd.edu (Dennis Lou) (02/16/91)
In article <24216@netcom.COM> resnicks@netcom.COM (Steve Resnick) writes: >In article <1991Feb15.041246.15904@murdoch.acc.Virginia.EDU> dmk8r@plaid.cs.Virginia.EDU (Darrell M. Kienzle) writes: >>FYI, I just spoke to the people from Borland's Educational Sales >>Department, and was told that the price for C++ 2.0 was $99.95 >>through their program, postage paid. > >I just got my upgrade coupon. If you own TC or TC++ the upgrade price is >$149.95. If you own TC or TC++ Professional it's $99.95. It liss for $495.95 Hmmm, I think a better idea is for me to sell my existing TC++ Pro to someone and buy C++ 2.0 with the Edu discount... -- Dennis Lou || "But Yossarian, what if everyone thought that way?" dlou@ucsd.edu || "Then I'd be crazy to think any other way!" [backbone]!ucsd!dlou |+==================================================== dlou@ucsd.BITNET |Steve Jobs and Steve Wozniak went to my high school.
randall@Virginia.EDU (Ran Atkinson) (02/22/91)
Below are a few open questions that aren't clearly answered in the Borland upgrade offer notice and haven't been clearly addressed on the net. If you already have a copy of Borland C++ and can give a definitive answer, please either reply or followup to this posting. Please try to refrain from speculation if you don't really know for certain. Thanks. 1) Does the Borland C++ IDE run as a MS-Windows Application ?? 2) If not, will it get along with Windows as a DOS application ?? 3) Does the Borland Debugger run as a MS-Windows Application ?? 4) Does the Borland Debugger debug any MS-Windows application, or just those built with their tools ?? 5) Does Borland C++ have a switch to generate DPMI Compliant binaries ?? 6) Does Borland C++ have a switch to generate 386 Protected Mode binaries ?? 7) Does Borland C++ have a switch to generate 386 real mode binaries ?? 8) Does Borland ASM have a switch to generate DPMI Compliant binaries ?? 9) Does Borland ASM have a switch to generate 386 Protected Mode binaries ?? 10) Does Borland ASM have a switch to generate 386 real mode binaries ?? 11) How much disk space does the whole thing take up ?? Ran Atkinson randall@Virginia.EDU
wolf@netcom.COM (Phil Escobar) (02/23/91)
randall@Virginia.EDU (Ran Atkinson) writes: >1) Does the Borland C++ IDE run as a MS-Windows Application ?? >2) If not, will it get along with Windows as a DOS application ?? >3) Does the Borland Debugger run as a MS-Windows Application ?? I can cover these first three: 1) the IDE is NOT a true Windows application. It's nearly identical to the IDE in Turbo C++, with the addition of several new compiler options. 2) the IDE will work just fine in a DOS window, and that is the recommended way to use it. 3) the debugger IS a Windows app, but it doesn't run in a window (go figure) Also, Borland ships a bunch of neat Windows development utilities with the new C++ that put the Windows SDK tool to shame. - Phil @ Buckskin Technologies
yeates@motcid.UUCP (Tony J Yeates) (02/27/91)
dsampson@x102a.harris-atd.com (sampson david 58163) writes: > The windows debugger IS a windows >application, and YES!!! you can debug with only one monitor. However >they tell you in the manual that if you're using VGA, they support >standard VGA, not super or the psuedo 8514 resolution you can get with >the drivers floating around now. Pardon my ignorance, but I thought a major benefit of windows applications was that they used library routines which make them display-independent. (...or was the author refering to the DOS debugger?). Other windows applications seem to run on anything as long as it has a windows driver.. whats the deal with the debugger?
bcw@rti.rti.org (Bruce Wright) (02/28/91)
In article <5907@iron6.UUCP>, yeates@motcid.UUCP (Tony J Yeates) writes: > dsampson@x102a.harris-atd.com (sampson david 58163) writes: > > The windows debugger IS a windows > >application, and YES!!! you can debug with only one monitor. However > >they tell you in the manual that if you're using VGA, they support > >standard VGA, not super or the psuedo 8514 resolution you can get with > >the drivers floating around now. > > Pardon my ignorance, but I thought a major benefit of windows applications > was that they used library routines which make them display-independent. > (...or was the author refering to the DOS debugger?). Other windows > applications seem to run on anything as long as it has a windows driver.. > whats the deal with the debugger? Windows does hide the low-level implementation details from a program, so if the program works on one display device it's likely to do something at least slightly useful on another display device rather than just die like some DOS apps that encounter display devices that they don't know how to deal with. Unfortunately that's not quite the same as device independence. It is quite possible for a Windows program to get hold of the _logical_ structure of the display device; in fact for advanced graphics it's practically essential. For example, Windows allows a program to be aware of the pixel (width, height, bit planes) and physical (width, height, aspect ratio) attributes of the display device; this allows you to write programs that can work great on one device and yet do inappropriate things on another (such as choosing the wrong size fonts or inappropriate sizes or aspect ratios for various objects, or relying on colors that don't exist, etc). This sort of thing can mean that although the program does _something_ on a display device for which it wasn't intended, it doesn't do something very _useful_. This isn't to say that that's the usual case with Windows programs; just that it's possible. Most Windows programs probably don't have problems like this, but the more sophisticated programs (graphically speaking, not necessarily sophisticated in other ways) are the ones that are more likely to be doing fancy things and are therefore more likely to have problems. And of course poorly-written programs of any level of sophistication will have more problems than well-written programs. Even Microsoft isn't immune: try running Reversi on a CGA-resolution screen sometime. Perhaps there are problems of this type with the debugger, or perhaps they just don't want to commit themselves to fixing any problems at this time because they haven't had the time to test it sufficiently for their satisfaction. Or maybe they're replacing some of the low- level drivers for the device and haven't written this one yet (shudder), though offhand I don't see why that should be necessary. Bruce C. Wright
jim@shograf.COM (jim morris) (02/28/91)
From article <5907@iron6.UUCP>, by yeates@motcid.UUCP (Tony J Yeates): > dsampson@x102a.harris-atd.com (sampson david 58163) writes: >> The windows debugger IS a windows >>application, and YES!!! you can debug with only one monitor. However >>they tell you in the manual that if you're using VGA, they support >>standard VGA, not super or the psuedo 8514 resolution you can get with >>the drivers floating around now. > > Pardon my ignorance, but I thought a major benefit of windows applications > was that they used library routines which make them display-independent. > .... Well the BC++ debugger does run when windows is running, but it is not actually a windows application, its more like a DOS application that is being very friendly with windows. It runs full screen and looks and feels exactly like it does running under DOS. I don't know exactly what they have done, but it is NOT a windows App therefore it is not display independent like a windows App. I actually tried to run it while in 800x600 mode, it runs fine... But windows is screwed up when you exit as the video mode has been changed to character mode not graphics, and windows doesn't realise this and therefore doesn't reset the 800x600 mode. Still its a lot better than no debugger at all!! its even better than running a debugger on a separate system (Which you can still do). Still playing so can't review it yet..... Jim -- Jim Morris, E-Mail: jim@shograf.com Voice: (415) 903-3887 _ SHO graphics. Practical PEX
aaron@jessica.stanford.edu (Aaron Wallace) (03/01/91)
In article <1991Feb28.030702.4105@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: >In article <5907@iron6.UUCP>, yeates@motcid.UUCP (Tony J Yeates) writes: >> dsampson@x102a.harris-atd.com (sampson david 58163) writes: >> > The windows debugger IS a windows >> >application, and YES!!! you can debug with only one monitor. However >> >they tell you in the manual that if you're using VGA, they support >> >standard VGA, not super or the psuedo 8514 resolution you can get with >> >the drivers floating around now. >> >> Pardon my ignorance, but I thought a major benefit of windows applications >> was that they used library routines which make them display-independent. >> (...or was the author refering to the DOS debugger?). Other windows >> applications seem to run on anything as long as it has a windows driver.. >> whats the deal with the debugger? > >Perhaps there are problems of this type with the debugger, or perhaps >they just don't want to commit themselves to fixing any problems at >this time because they haven't had the time to test it sufficiently >for their satisfaction. Or maybe they're replacing some of the low- >level drivers for the device and haven't written this one yet (shudder), >though offhand I don't see why that should be necessary. > On the subject of on-screen, windowed debuggers: Off hand I'd suspect the problem is as follows: say your program goes around creating a whole bunch of GDI objects and, by a bug, forgets to delete them. From experience, this is a good way to kill off Windows. Now, if the GDI heap is full when the debugger needs to be called up, it's hard to see how the debugger will get much on the screen. As for not supporting non-"normal" displays, perhaps it's because in the case of a bad crash it's not possible to tell Windows to kick into the right mode, and it would be very difficult for BOrland to support every Windows-compatible display separately. (It could call the display driver, but that assumes enough memory to load the .DLL...) I imagine it's for reasons similar to this that the Mac debugger switches to a full-screen text mode; it might not be able to do graphics if the bug is bad enough... But enough hypothesizing... Aaron Wallace
wallis@sieras.enet.dec.com (Barry L. Wallis) (03/01/91)
In article <553@shograf.COM>, jim@shograf.COM (jim morris) writes... >Well the BC++ debugger does run when windows is running, but it is >not actually a windows application, its more like a DOS application >that is being very friendly with windows. It runs full screen and looks >and feels exactly like it does running under DOS. I don't know exactly what >they have done, but it is NOT a windows App therefore it is not display >independent like a windows App. I actually tried to run it while >in 800x600 mode, it runs fine... But windows is screwed up when you exit >as the video mode has been changed to character mode not graphics, and windows >doesn't realise this and therefore doesn't reset the 800x600 mode. > I am new to Windows programming and am using Borland C++ to get started. I noticed that when I leave the debugger the Active Title Bar (is that what it's called?) has changed from grey (or whatever the default color is) to maroon. Any idea on how to stop this? Alternatively, is there anything I can do to change it back (short of exiting windows). This is a BOCA EGA 286 systems with 2MB of extended memory. --- Barry L. Wallis USENET: wallis@labc.dec.com Database Consultant Prodigy (don't laugh): DNMX41A U.S. DECtp Resource Center DECUServe: EISNER::WALLIS (not on the net yet) Los Angeles, CA "No one voted for me, I represent myself" ---
dsampson@x102a.harris-atd.com (sampson david 58163) (03/01/91)
Actually, I mis-led you on one point. The Turbo Debugger for windows is NOT actually a windows application the way Notepad is. You DO start it up by double clicking the icon and you don't need a PIF file like you do with conventional DOS programs. So Turbo Debugger is sort of half way in between a conventional DOS application and a windows application. When you fire up TD for W, it runs in full screen and looks like the "regular" Turbo Debugger, that is it is rows and columns of text, not a windows program with a main window etc. However, it definitely debugs your windows code and let's you switch between your windows app that's being debugged and the TD screen with a key-stroke (can't remember if it was Alt-F5, or what). Borland states in their docs that the "regular" TD supports cga, ega, vga, super VGA, and so forth. But to use TD for Windows in VGA mode you must stay with the conventional (i.e. MS supplied) VGA driver for windows, not one supplied by your card vendor. -- A new world record in the javalin throw / / / I ------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
bcw@rti.rti.org (Bruce Wright) (03/01/91)
In article <1991Feb28.173016.22964@leland.Stanford.EDU>, aaron@jessica.stanford.edu (Aaron Wallace) writes: > In article <1991Feb28.030702.4105@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: > >Perhaps there are problems of this type with the debugger, or perhaps > >they just don't want to commit themselves to fixing any problems at > >this time because they haven't had the time to test it sufficiently > >for their satisfaction. Or maybe they're replacing some of the low- > >level drivers for the device and haven't written this one yet (shudder), > >though offhand I don't see why that should be necessary. > > On the subject of on-screen, windowed debuggers: > Off hand I'd suspect the problem is as follows: say your program goes around > creating a whole bunch of GDI objects and, by a bug, forgets to delete them. > From experience, this is a good way to kill off Windows. Now, if the GDI > heap is full when the debugger needs to be called up, it's hard to see how the > debugger will get much on the screen. As for not supporting non-"normal" > displays, perhaps it's because in the case of a bad crash it's not possible to > tell Windows to kick into the right mode, and it would be very difficult > for BOrland to support every Windows-compatible display separately. (It could > call the display driver, but that assumes enough memory to load the .DLL...) Umm. Maybe. But if you have a debugger which is running in a window on the screen, I don't see how it helps very much that GDI is talking to a standard VGA rather than to a super-VGA, for example. The problem is that if Windows runs out of handle space (for example), there's probably not a safe way to unjam the situation in _ANY_ display resolution. In other words, in this situation the problem is going to be with the Windows data structures, not with the code to support the screen itself. Hard to see how you can fix up the basic data structures when Windows is running on one screen and not when it's running on another. But it appears that the problem is completely different: I (and from some of the conversation on this thread, I suspect others as well) had assumed that the debugger was running in a _window_ like, for example, some of the debuggers for X-Windows systems. This is apparently not the case: In article <DSAMPSON.91Feb28150739@x102a.harris-atd.com>, dsampson@x102a.harris-atd.com (sampson david 58163) writes: > When you fire up TD for W, it runs in full screen and looks like the > "regular" Turbo Debugger, that is it is rows and columns of text, not > a windows program with a main window etc. However, it definitely > debugs your windows code and let's you switch between your windows app > that's being debugged and the TD screen with a key-stroke (can't > remember if it was Alt-F5, or what). This explains what's going on - they solve the problem by taking over the _entire_ screen, therefore can't run in a window, therefore don't have to deal with GDI, etc. Or in other words, yes, in a sense they _did_ write their own drivers for the device, though not in the sense I thought they meant: it's apparently just a character-mode driver of some sort. And since the way you swap between character mode and super-VGA mode isn't completely standardized, I guess that may be the problem with supporting super-VGA resolutions in the debugger. Bruce C. Wright
timur@seas.gwu.edu (The Time Traveler) (03/02/91)
In article <20624@shlump.nac.dec.com> wallis@sieras.enet.dec.com (Barry L. Wallis) writes: > >In article <25988@rouge.usl.edu>, pcb@basin04.cacs.usl.edu (Peter C. Bahrs) writes... >!>Is it just a C++ compiler that is win3 kernel callable? i.e. I can >!>call the sdk functions. > >It's the former. It uses the Microsoft WINDOWS.H file and you do the standard >Windows calls. Time to reinvent the wheel, I guess. > Wait a minute .... Does this mean that I need to have Microsoft's Windows 3.0 SDK to compile BC++ Windows programs? I thought that BC++ came with everything I needed. ----------------------------------------------------------- The Time Traveler Sadder still to watch it die a.k.a. Timur Tabi Then never to have known it Internet: timur@seas.gwu.edu For you - the blind who once could see - Bitnet: HE891C@GWUVM The bell tolls for thee -- Rush
hardiman@csd4.csd.uwm.edu (Paul V Hardiman) (03/03/91)
The Programmer's Shop (Hingham, MA) in their spring 1991 catalog is offering a package including Borland C++, Glockenspiel (?) Common View 2, and the Petzold book for $475. Offer good through 4/27. I think common view 2 consists of C++ classes that handle GUIs for multiple platforms (Windows, PM, Motif, etc.). This package should reduce the number of wheels that need to be re-invented when using Borland C++ for Windows developmnt. (I have no relationship with Borland or Glockenspiel.)
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/04/91)
No you don't need the SDK to compile Windows applications with BC++. I've had the package a week and am compiling & linking & running a Windows application successfully. What you will need: a book on Windows programming (Petzold's is highly recommended). Apparently there's a discount coupon for the book in the BC++ box somewhere. Eric Terrell (impressed with BC++)
wallis@sieras.enet.dec.com (Barry L. Wallis) (03/04/91)
In article <2814@sparko.gwu.edu>, timur@seas.gwu.edu (The Time Traveler) writes... >In article <20624@shlump.nac.dec.com> wallis@sieras.enet.dec.com (Barry L. Wallis) writes: >> >>In article <25988@rouge.usl.edu>, pcb@basin04.cacs.usl.edu (Peter C. Bahrs) writes... >>!>Is it just a C++ compiler that is win3 kernel callable? i.e. I can >>!>call the sdk functions. > >> >>It's the former. It uses the Microsoft WINDOWS.H file and you do the standard >>Windows calls. Time to reinvent the wheel, I guess. >> > >Wait a minute .... Does this mean that I need to have Microsoft's >Windows 3.0 SDK to compile BC++ Windows programs? I thought that BC++ >came with everything I needed. > Sorry for any confusion I might have caused. You need *nothing* else (except documentation) to develop Windows 3.0 programs with Borland C++. I'm up to chapter 3 in the Petzold book and everything works like a charm. I also tried compiling *all* the Windows 3.0 example programs. They all compiled and ran successfully (there is a minor bug in the TODO, but, who's counting). BTW, the only real documentation on Windows that BC++ comes with is in the form of their on-line help library. I wonder if they licensed that from MS also, as it is formatted differently (and somewhat poorly) than the standard Borland help screens. --- Barry L. Wallis USENET: wallis@labc.dec.com Database Consultant Prodigy (don't laugh): DNMX41A U.S. DECtp Resource Center DECUServe: EISNER::WALLIS (not on the net yet) Los Angeles, CA "No one voted for me, I represent myself" ---
johnm@spudge.UUCP (John Munsch) (03/05/91)
In article <2814@sparko.gwu.edu> timur@seas.gwu.edu () writes: >In article <20624@shlump.nac.dec.com> wallis@sieras.enet.dec.com (Barry L. Wallis) writes: >>In article <25988@rouge.usl.edu>, pcb@basin04.cacs.usl.edu (Peter C. Bahrs) writes... >>!>Is it just a C++ compiler that is win3 kernel callable? i.e. I can >>!>call the sdk functions. > >>It's the former. It uses the Microsoft WINDOWS.H file and you do the standard >>Windows calls. Time to reinvent the wheel, I guess. >> > >Wait a minute .... Does this mean that I need to have Microsoft's >Windows 3.0 SDK to compile BC++ Windows programs? I thought that BC++ >came with everything I needed. No. Borland C++ comes with everything you need to write Windows 3.0 programs. The ONLY thing it does not do that the SDK will do is allow you to create Windows Help compatible help files. I consider this a oversight and I expect it to be corrected by Borland. The original discussion was whether or not Borland included a set of class libraries to encapsulate the Windows functions or whether you had to create that yourself. John Munsch
oneel@heawk1.rosserv.gsfc.nasa.gov ( Bruce Oneel ) (03/05/91)
Re: borland C++ and help files. According to Borland on CI$, the help compiler was held up over legal matters and didn't go to the people who get early copies of BC++. In a few weeks (I heard 4-6, but that was almost 2 weeks ago) the help compiler will be sent to those people who didn't get it origionally. bruce -- | Bruce O'Neel | internet : oneel@heasfs.gsfc.nasa.gov| | Code 664/STX | span : lheavx::oneel | | NASA/GSFC |compuserve: 72737,1315 | | Greenbelt MD 20771 | AT&Tnet : (301)-286-1119 |
wallis@sieras.enet.dec.com (Barry L. Wallis) (03/06/91)
>No. Borland C++ comes with everything you need to write Windows 3.0 >programs. The ONLY thing it does not do that the SDK will do is allow you >to create Windows Help compatible help files. I consider this a oversight >and I expect it to be corrected by Borland. > According to a Borland R&D employee (Sidney Markowitz) the reason the Help Compiler (is that what its called?) wasn't shipped with BC++ originally was that the contracts between MS and Borland for that product had not yet been completed by the February 13 announcement date and they didn't want to announce the product and not ship it (a wise move IMHO). Within 3 - 4 weeks they expect to be shipping the Help Compiler and a 33% discount coupon for the Petzold book to all those who got BC++ by mail. --- Barry L. Wallis USENET: wallis@labc.dec.com Database Consultant Prodigy (don't laugh): DNMX41A U.S. DECtp Resource Center DECUServe: EISNER::WALLIS (not on the net yet) Los Angeles, CA "No one voted for me, I represent myself" ---
dmatlock@eecs.cs.pdx.edu (Delbert Matlock) (03/07/91)
timur@seas.gwu.edu (The Time Traveler) writes: >In article <20624@shlump.nac.dec.com> wallis@sieras.enet.dec.com (Barry L. Wallis) writes: >> >>In article <25988@rouge.usl.edu>, pcb@basin04.cacs.usl.edu (Peter C. Bahrs) writes... >>It's the former. It uses the Microsoft WINDOWS.H file and you do the standard >>Windows calls. Time to reinvent the wheel, I guess. >> >Wait a minute .... Does this mean that I need to have Microsoft's >Windows 3.0 SDK to compile BC++ Windows programs? I thought that BC++ >came with everything I needed. Actually, Borland licensed some parts of the SDK to include in BC++. All you need in addition to Borland C++ is a Windows programmer's reference manual if you want to write programs for Windows 3.0. ============================================================================= Delbert Matlock Internet: dmatlock@eecs.cs.pdx.edu MicroNet Northwest Voice: (503)228-3071