[delphizip] Re: Source code formatting for DLLs
- From: Eric.Engler@xxxxxxxxxxxxxx
- To: delphizip@xxxxxxxxxxxxx
- Date: Mon, 1 Apr 2002 13:14:10 -0500
I've always been using either __stdcall or WINAPI as the types of the
exported functions. The call to load the DLLs is working (part of that is to
get the addresses of the exported functions), and the call to get the
version number is working.
The main call to Zip or unzip is also working initially - if I put a call to
show a message directly after the main function is called the message will
get displayed.
So we clearly do not have a name mangling problem and the parameter passing
is working at least in the call to get the version number.
Eric
-----Original Message-----
From: Russell Peters [mailto:russellpeters@xxxxxxxxxxx]
Sent: Monday, April 01, 2002 1:49 AM
To: delphizip@xxxxxxxxxxxxx
Subject: [delphizip] Re: Source code formatting for DLLs
I found a bit of an article describing call types (my memory was a bit
rusty)
(taken from
http://www.wd-mag.com/articles/1998/9808/9808d/9808d.htm?topic=articles)
...
The calling sequence specifies three things: argument order, stack cleanup,
and naming convention.
First, under Win32, both __stdcall and __cdecl require arguments to be
pushed on the stack from right to left - reverse order, in other words. As
you can see in Figure 1, when you pass arguments a and b to a function, the
compiler generates code that pushes first b and then a onto the stack.
Second, __stdcall requires the callee to clean up the stack (pop the pushed
parameters off), while __cdecl requires the caller to handle stack cleanup.
Because of this, __cdecl can support functions that take a variable number
of arguments (e.g., printf()), since in that case the callee cannot know at
compile time how many parameters need to be popped. In Figure 1, you can see
that the __stdcall function ends in a RET 8 instruction (popping two
four-byte parameters), while the __cdecl function ends in a simple RET
(since the caller has to adjust the stack pointer).
Finally, the calling sequence affects the actual exported name generated by
the compiler and linker, and Microsoft and Borland use different conventions
for this. Microsoft mangles __stdcall names by default, so a function
declared as:
int __stdcall Foo(int a)
would by default get assigned a name of "_Foo@4" by Visual C++, but would be
named "Foo" by Borland C++. With __cdecl, the same function would be named
"Foo" by Visual C++, but "_Foo" by Borland C++. With both compilers, you can
use a .def file to alias the exported function name to whatever you want,
and most DLLs intended for wide reuse follow the convention of the Win32
API: __stdcall function names are not mangled, and __cdecl functions (the
less common case) have a "_" prepended to their name.
This discussion of mangling assumes you're either compiling with C, or are
exporting functions from C++ using the extern "C" directive. Otherwise, C++
will impose its own name mangling scheme.
...
I am not sure how to stop the name mangling (does it actually do it with c
code?)
but ZipBuilder was built for __stdcall (of course ZipBuilder can always get
altered for the new dll's but this would mean you could not use the old
ones)
Hope this helps to clarify why it locks up.
- Russell
----- Original Message -----
From: "Russell Peters" <russellpeters@xxxxxxxxxxx>
To: <delphizip@xxxxxxxxxxxxx>
Sent: Monday, April 01, 2002 3:43 PM
Subject: [delphizip] Re: Source code formatting for DLLs
> I'd say your problem is the interface with ZipBuilder -
> Your secondary entry points probably need to be
> __stdcall long
> ie
> extern __stdcall long GetUnzDllVersion( void );
> extern __stdcall long GetUnzDllPrivVersion( void );
> extern __stdcall long UnzDllExec( DCL1 *C );
> but definately the callback must be declared
> /* Define a type called DLLCALLBK: */
> typedef __stdcall unsigned long (*DLLCALLBK)(CallBackStruct *);
> or it will freeze (or worse) after return from it.
> - Russell
> ----- Original Message -----
> From: "Eric Engler" <englere@xxxxxxxxxxx>
> To: <delphizip@xxxxxxxxxxxxx>
> Sent: Monday, April 01, 2002 2:43 AM
> Subject: [delphizip] Source code formatting for DLLs
>
>
> > I have updated the "betadllsrc.zip" file on my
> > web site. The source files have been reformatted
> > to make them look much better!
> >
> > I have included the code to initialize the DLLs,
> > but there is still a problem somewhere. I'll
> > look into it further.
> >
> > I also have a nice Delphi source code formatter that
> > I'll explain in the future. For now I'm working on the
> > DLLs.
> >
> > Here's some more info:
> >
> > Auto Formatting of C Source Files
> >
> > Some programmers don't like source code formatting
> > programs because they can make formatting changes that
> > aren't desired, or in some cases they can actually "break"
> > a source file.
> >
> > I started out hating formatting programs, but over the years
> > I have changed my mind. There is a lot of C source code in
> > the Delphi Zip DLLs, and it's too hard to keep formatting
> > the code "by hand". I have decided to use the GNU "indent"
> > program to automatically format the source files to make
> > them easier to understand.
> >
> > You must use this "indent" program with extreme caution
> > because it is possible that a source file can be damaged. If
> > you spot the error message you can often figure out what
> > went wrong. You can then edit the source file to make it
> > easier for the indent program to do it's job correctly, and
> > then you can run the formatter again.
> >
> > See my web site for "betadllsrc.zip":
> > http://www.geocities.com/SiliconValley/Network/2114/
> >
> >
>
>
Other related posts:
