Subj : Re: bcc 5.02 command line v. ide
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Thu Dec 02 2004 10:43 am

> > The IDE uses DLL versions of the compiler and linker so
> > does not use the same physical compiler and linker as a
> > command line build.

> Ok, that is scary.  It means that in theory we could end
> up with different object code for from the same source
> code.

Not really.  It is the same code base.  The wrapper and a
couple of modules giving extra capability are what is
changed.  For example: the DLL is launched as a DLL instead
of as a standalone program so accepts commands from the
loading program instead of from a user's command line.

Because the IDE uses a hunk of memory not in use when
running from the command line the module to generate an
assembly source file in a form for users to view was only in
the command line compiler. I think that restriction was
removed with version 5 of the compiler because the IDE in 5
is 32 bit based and expected to have a larger memory
environment.

> ... I'll try that with a broken down into an individual
> projects version, and see what I get. ...

FYI:
For production code I always make an individual project for
each target.

> ... I am also looking for some 32bit serial port ISR code,
> is yours available anywhere? ...

I don't have 32 bit serial port ISR code.  32 bit Windows
already contains one of them and provides an API for using
the port.

If you wanted to drive the serial port yourself in 32 bit Windows
you would have to create a virtual device driver (VxD, Win95/98)
and a kernel mode driver (WinNT/2K/XP) and arrange for them
to both supply the services expected by Windows and replace
the one Windows provides.

..  Ed

> David Morris wrote in message
> news:41aeb9ed@newsgroups.borland.com...
>
> Firstly Ed, let me thank you for taking the time to reply.
>
> > The IDE uses DLL versions of the compiler and linker so
> > does not use the same physical compiler and linker as a
> > command line build.
>
> Ok, that is scary.  It means that in theory we could end
> up with different object code for from the same source
> code.
>
> > I do not think the C++ option setting have any effect on
> > a C language build EXCEPT for the runtime type id (RTTI)
> > and exception handling (EH).   I prefer building from
> > the command line and for C builds I always specify -RT-
> > (RTTI off) and -x- (EH off) as well as linking with
> > noeh?.lib ('?' is 1st letter of memory model) or
> > noeh32.lib to stub out any remaining RTTI and EH found
> > in the libraries.  The difference in executable size
> > from doing that is noticable.
>
> I had tried those settings, which did not appear to make
> any difference, probably because I linked noehl.lib, (this
> is, unsurprisingly, the large model), for exactly the
> reason you suggested (exe size).
>
> > My serial comm ISR's always have a trap bit which
> > detects if the ISR is still active at the beginning of
> > the IS  E.If that happens I do the handshake and then
> > IRET immediately. (My ISR's are all assembly - none are
> > written in C.)
>
> The serial port ISR is some very old code that I (and I
> rarely do this) recycled from some PD code available on
> the Net, and then modified to fix a few things and to add
> handshaking.  I am going to have to remember how that part
> works (I think I did this in 1995 or 96).  I vaguely
> remember having to do something like this elsewhere for
> DOS since it wasn't re-entrant - but I am getting brain
> fade now.
>
> Any clues? (hint?). [ Actually, I am also looking for some
> 32bit serial port ISR code, is yours available anywhere?
> (that would be a double hint? hint?)]
>
> > If your code depends upon specifics of where things are
> > placed into DGROUP with respect to each other you should
> > consider rewriting it to remove such things.  That kind
> > of thing is a common source of memory being written to
> > when it shouldn't be.
>
> No it is isn't.  I meant that, the obj modules might be
> getting linked in a different order, and thus changing the
> order of variables in DGROUP, which is why I am seeing the
> error only when built from my make file.  I suspect that
> somewhere something is being overwritten, but is happens
> to be over some space that is not being used for anything
> vital at the time - rather scary when I think about it.  I
> thought that I had long ago resolved any buffer over run
> errors.  [It certainly doesn't leak.  I have had a client
> run the software literally for years without stoping it
> (when they did it was because the monitor had failed!)]
>
> > As for make files, I find the IDE-generated ones to be
> > too complex and write my own.
>
> Absolutely!!!    Mind you I suspect that mine are "write
> only" as the IDE ones to anyone else.  (Though at least I
> can pretend to understand them.)
>
>
> > If you have an IDE generated make file then a good place
> > to start is to do this to capture what is actually being
> > done without tons of unused macros clouding the picture:
> > make -K -n -f filename.mak >somename.txt
>
> That is cool idea.  However, the IDE make file is too
> complex even for make!
>
> MAKE Version 5.0  Copyright (c) 1987, 1997 Borland
> International
> Error: Circular dependency exists in makefile
>   drivers\lib\pabxdrv.lib -  drivers\lib\pabxdrv.lib
>  Copy MAKE0257.@@@ BccW16.cfg
>  TLib C:\WORK\MONTEL\SRC\LIB\assert.lib /0 /E
> @MAKE0029.@@@
>  TLib C:\WORK\MONTEL\SRC\LIB\time.lib /0 /E
> @MAKE0085.@@@
>  TLib C:\WORK\MONTEL\SRC\LIB\pabxlib.lib /0 /E
> @MAKE0000.@@@
> Fatal: 'pabxdrv.lib' does not exist - don't know how to make it
>
> I'll try that with a broken down into an individual
> projects version, and see what I get.

.