Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!unido!gmdzi!strobl From: strobl@gmdzi.UUCP (Wolfgang Strobl) Newsgroups: comp.windows.ms Subject: Re: Borland C++ with Windows 3.0? Message-ID: <3046@gmdzi.UUCP> Date: 5 Jul 90 19:52:01 GMT References: <604@cvbnetPrime.COM> Organization: GMD, Sankt Augustin, F. R. Germany Lines: 43 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