Subj : Re: Well...
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Mon May 03 2004 11:33 am

I do not know what you expect these lines from the module definition
file to do.  They are not of the format required by the HEAPSIZE and
STACKSIZE entries.

> HEAPSIZE    9216; 8192; 6144; 5120; 4096
> STACKSIZE   18432; 17108; 16384; 15360 ;14336; 13312

For example, here is a copy of the entry in the help for the stacksize
statement:

  --------------------
  STACKSIZE Module-Definition Statement STACKSIZE bytes

  The STACKSIZE statement specifies the number of bytes
  needed by the application for its local stack. An
  application uses the local stack whenever it makes
  function calls.

  Parameter Description

  bytes Specifies the stack size, in bytes. If the
  application makes no function calls, the default stack
  size is zero. If your application does make function calls
  and you specify a stack size smaller than 5K, Windows
  automatically sets the size to 5K.

  Comments

  Do not use the STACKSIZE statement for dynamic-link
  libraries (DLLs).

  Example

  This example sets the size of an application's stack to
  6,144 bytes.

  STACKSIZE 6144
  --------------------

For information on the statements that are put into Module Definition
files (*.DEF files), start the Windows help, WIN31WH.HLP, click on
Search and in the Index type Module Definition Statements.  Note that
this information is compiler-independent.  The statements of which I
am speaking were as incorrect for Visual C++ as they were for Borland
C++.

In the DEF file you also list GETMODULEPTR as an export from your
program.  Your program is an exe, an executable, and normally would
not have any such exports.  As I mentioned in my last reply to you,
the name is one used for an OWL function.

> "Other symbols such as _NextColor and _GetPlotWindow
> appear to come from other or 3rd party software that
> probably have their own library so their library or libraries
> should be listed as part of the project file."
>
> -They are listed as a part of the project, but the Borland doesnt
> see them !!! (I think!)

If the items which provided those public symbols were part of the
project then the software certainly would see them.  The problem
involves the public names of the functions which are not necessarily
the same as the names as seen in the source code.

For example, a function named NextColor which is named as a C function
would be expected to have a public name of _NextColor.  If it were
identified with WINAPI, CALLBACK, PASCAL or _pascal then it would use
pascal calling conventions so the symbol available in the object file
or library would be NEXTCOLOR.

Check the header files used.  The function prototypes could have a
problem.  Also check the public name for the symbols.

For example, if I were checking what the situation with _NextColor was
I might do something like this:

Set the directory where the library or object file containing
_NextColor was located as the default.   Assuming that the file
containing it was named n.obj (substitute the actual name) run the
following command:

  tdump -m n.obj | grep -i "nextcolor"


The name it finds might be similar to one of these:

  _NextColor
  that is what the program was searching and could not find
  so the library is probably not part of the project.

  NEXTCOLOR
  the function prototype needs WINAPI or PASCAL as in
  int WINAPI NextColor(whatever the argument list is);

  @NextColor$qvi
  the function is a C++ function but is being called as a C one


> Untill now, I have compiled the 1.3xx.xxx lines of codes!
> There are few thousands be left!

I do not understand why people spend time working with millions of
lines of 16 bit Windows code when the best they can achieve is to
create a program for an operating system that has been obsolete for 9
years.

..  Ed

> Namik Nuhanovic wrote in message
> news:4096243c$1@newsgroups.borland.com...
>
> I am using Borland C++ 5.02 for a first time!!! :))
> (I use MS Visual Studio)
>
> The thing is:
>
> I got the source code, and i have to give .exe ! I think that the
> source i'm working on, is written in Borland C++ 4.5 version. Is
> this important !?
>
> I have also the .DEF file, i tried to do something, but doesnt work!
>
> // there is this one .DEF ...
>
> NAME mdiglop
>
> EXETYPE     WINDOWS
> CODE        PRELOAD MOVEABLE DISCARDABLE
> DATA        PRELOAD MOVEABLE
> HEAPSIZE    9216; 8192; 6144; 5120; 4096
> STACKSIZE   18432; 17108; 16384; 15360 ;14336; 13312
>
> // ...and there is something like this
>
> EXPORTS
>     WEP                            @1
>     INITCEALCKEY                   @2
>     CHECKCEALCKEY                  @3
>     CMABOUTCEALCAPP                @4
>     CMCEALCKEYUTILITY              @5
>     GETDOCTEMPLATEHEAD             @6
>     GETMODULEPTR                   @7
>
> Which one, and where to put it, I dont know ! :((
> I tried everything,...
>
> And...You said:
> "Other symbols such as _NextColor and _GetPlotWindow
> appear to come from other or 3rd party software that probably
> have their own library so their library or libraries should be
listed
> as part of the project file."
>
> -They are listed as a part of the project, but the Borland doesnt
> see them !!! (I think!)
>
> Untill now, I have compiled the 1.3xx.xxx lines of codes! There are
> few thousands be left!

.