[Winpcap-users] RE: TCP/IP stack - reinventing the wheel

[Thomas O'Hare]

Will do!

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...  ;-)

Much Thanks,
~ 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
>> manner.
>>
>> 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):
> 
> http://blogs.msdn.com/oldnewthing/archive/2004/01/12/57833.aspx
> 
> 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.
> 
> and:
> 
>> 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
> functions.
> 
> 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
> https://www.winpcap.org/mailman/listinfo/winpcap-users