I have several in-house written C dlls.  They are written in standard
Ansi C, using the Borland C++  version 4.51 environment.  What do I need
to change to convert them from 16-bit dlls to 32-bit dlls?  I have
searched for any helpful documents or books, but I have found nothing.

Jennifer Sacks
SatoTravel

The compiler?

There is no documentation that I would be aware of that addresses strict
ANSI C code - which really should port with a simple recompile.

--
General information:
  * Post to the right group - http://www.borland.com/newsgroups/
    * Do not cross- or multipost
      * Research at http://www.mers.com/searchsite.html

Stefan Hoffmeister - http://www.econos.de/
TeamB - http://www.teamb.com/

SatoTravel,

Depends on the compiler but the port we did highlighted the following
when moving from BC4.52 to BC5.01

  1.for() loops.
  Declaring a variable inside the for() declaration causes problems
because in later C++ the scope is restricted to the for() so:

  for( int fred=0;fred<10;++fred )
  {
  }

  printf( "%i", fred );

  Won't work because fred is out of scope at the printf() call.

  2.If you've used 'int' anywhere you are in for a rough(ish) ride.
  The more places you've used 'int' the worse it will be.

  3.Alignment
  4.51 defaults to byte alignment. 5.01 defaults to DWORD, BCB4 QWORD.

Our experience of porting from 4.5 to 5.x was pretty painless (we
hardly ever used 'int' anyway. In terms of code changes there were very
few required. Overall I think it would be safe to say that the code
recompiled more or unless unchanged.

Unfortunately in trying to move the resultant source to BCB we have run
into a serious problem. For some reason even though the same code is
being used in both projects the BCB .DLL is unstable and suffers heap
corruption almost immediately. We have yet to resolve this and at
present we're sticking with 5.01.

Andrue Cope
[Bicester, UK]

Structure packing and default integer sizes will be your biggest problems. Ints
are, almost by definition, 16 bits (2 bytes) in the 16 bit world, and 32 bits (4
bytes) in the 32 bit world. This should only matter in structures that are
saved to disk, if you are concerned with supporting older save files. Ditto with
structure packing, which is a problem when you move to any new compiler.

You may also have problems with the code itself compiling, as the standard
has changed some over the years. But for straight ANSI C code, the port shouldn't
be bad at all.

Also, 32 bit DLLs have a complete different entry mechanism than do 16 bit DLLs.
They only have one entry point (DllMain):

BOOL   WINAPI   DllMain (HANDLE hInst,
                        ULONG ul_reason_for_call,
                        LPVOID lpReserved)

and there is no more WEP exit point.

+===================================================+
| Jonathan Arnold (mailto:jdarn...@buddydog.org)    |
| http://www.buddydog.org                           |
+===================================================+

It never occurs to a boy that he will some day be as
dumb as his father. -- Dr. Laurence J. Peter

One thing to watch for that I came across was that not everyone used the
typical
conditional export and import modifiers in 16 bit DLL's. In 16 bit DLL's it
was
sufficient to just say _export in both the library and the application.
However,
in 32 bits, you have to get imports and exports right, otherwise you will
crash
when accessing static variables inside the DLL. This may be the heap problem
one respondent spoke of.

For good examples, look at some Borland header files.

int's shouldn't be the problem some are claiming.

My own opinion - why on earth use a DLL? In many cases a static library is a
much
more sensible solution, and will prevent many of the pitfalls into DLL hell.

- Neil.

news:38C7F655.75360225@satotravel.com...