[Winpcap-users] RE: TCP/IP stack - reinventing the wheel
Tom at RedTile.Com
Wed Aug 16 17:57:16 GMT 2006
And yes, I have done too much reading. Is it me, or is it many (most?)
of these writers get in a "trance" and just start pounding away at the
keyboard with no end in sight!
Which is why I try to locate "reference manuals" rather then "War &
Peace" novels. I just need to find a quick reference and move on. Not
go into "la la land" about all the concepts they can think of.
OK, sorry to "rant" on this list, I apologize if I appear to do so.
But if anyone has any "reference manuals" in their "Favorites" or
"bookmarks" folder I would love to see them.
Gawd, I love this list, great info, great people, all tech and no BS.
Hopefully I have not changed it... ;-)
~ Thomas O'Hare ~
President, RedTile, Inc. - DBA: RedTile Software
Web, Wireless, Network, Database & Systems Software
+1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
Operations Manager; Virtual FoxPro User Group
Tom at VFUG.Org ; http://www.VFUG.Org/
Bryan Kadzban wrote:
> On Wed, Aug 16, 2006 at 03:38:10PM +0000, Thomas O'Hare wrote:
>> My last stumbling block is exporting functions in an easy as possible
>> I know there are several methods (DEF, macro, etc), several types of of
>> Libraries (static, dynamic, etc), but I just want the easiest, safest
>> and fastest way to have my functions available to an external program.
> I'd recommend doing a bit of reading (...like you haven't already!).
> Specifically, this article written by Raymond Chen (shell and
> back-compat guru at Microsoft):
> Note especially these excerpts:
>> The dllexport attribute tells the linker to generate an export table
>> entry for the specified function. This export entry is decorated.
>> So if you intend people to be able to GetProcAddress for functions and
>> you intend your code to be portable to multiple platforms, or if you
>> intend them to be able to use your DLL from a language other than
>> C/C++ or use a C++ compiler different from Microsoft Visual Studio,
>> then you must export the function by its undecorated name.
> The important part of that last bit is the "from a language other than
> C/C++" part. VB.net and C# (and any language that uses .net P/invoke)
> calls into the DLL functions using the pointer returned by this
> GetProcAddress API. So if you intende to use a DLL from any .net
> language using p/invoke, you'll have to export the undecorated names.
> This is probably easiest if you use a .def file, and then omit the
> DLLEXPORT macros and __declspec(dllexport) specifiers on the exported
> You will have to create a dynamic library, not a static library. Static
> libraries link the DLL's code into each program that uses the library,
> so you end up with multiple copies floating around all over the place as
> a part of larger executables. Dynamic libraries create DLL files, which
> can be shared.
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
More information about the Winpcap-users