On Tue, Jun 07, 2005 at 12:26:11AM -0700, Guy Harris wrote:
> >Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm
> >forced to distribute my application with tons of DLL (MSVC*.DLL), which are
> >far bigger than the application itself.
> >Therefore, I'm always using the standar
Fulvio Risso wrote:
Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm
forced to distribute my application with tons of DLL (MSVC*.DLL), which are
far bigger than the application itself.
Therefore, I'm always using the standard C library.
The difference here, for the benef
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Christian
> Kreibich
> Sent: lunedì 6 giugno 2005 23.33
> To: tcpdump workers
> Subject: Re: [tcpdump-workers] pcap_dump_file & CO
>
>
> Hi Loris,
>
> On Fri, 20
Hi Loris,
On Fri, 2005-06-03 at 10:10 -0700, Loris Degioanni wrote:
> Guy,
>
> Guy Harris wrote:
> >
> > However, it sounds as if that only applies if the DLL is using a
> > different version, or different instance, of the C runtime:
>
> Yes, but this doesn't solve the problem. You just cannot
Guy Harris wrote:
Mark Pizzolato wrote:
> In the MS CRTL, a fpos_t
> is a 64bit integer, while on other platforms it may be a structure of
> some sort.
Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on
Windows?
Well, I've used this functionality for going on 8 years and i
Loris Degioanni wrote:
So no all Unix systems have types.h?
Not all UN*X systems necessarily have a types.h that define u_int64_t or
uint64_t.
What about using something like the
bittypes.h in the missing folder of tcpdump?
That might be one way.
Can the MSVC++ I/O routines handle files
Mark Pizzolato wrote:
In the MS CRTL, a fpos_t
is a 64bit integer, while on other platforms it may be a structure of
some sort.
Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on
Windows? (It doesn't matter about UN*X, as ftello() can be used there,
and, as I understand
Loris Degioanni wrote:
Guy Harris wrote:
> Loris Degioanni wrote:
> Can the MSVC++ I/O routines handle files >4GB? In at least some UN*Xes
Yes they can.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__tell.2c_._telli64.asp
I'm not sure, however, if the
Guy Harris wrote:
Loris Degioanni wrote:
I've removed pcap_fopen_offline() and pcap_dump_fopen() from the
WinPcap exports and manual.
OK - should we #ifdef them out on Win32, so that they're not even
compiled into the library? (And then update the man page to say "not
available on Window
Loris Degioanni wrote:
I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap
exports and manual.
OK - should we #ifdef them out on Win32, so that they're not even
compiled into the library? (And then update the man page to say "not
available on Windows".)
Just a small no
I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap
exports and manual.
I've added pcap_dump_ftell(), and I've tested everything with the today
tcpdump sources: -C now works correctly on Windows.
I had to make a small fix to the DSP of tcpdump in order to have
print-dhcp6.c
On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote:
Consistency of the API across different platforms, taking into
consideration that some of them could have serious rerstrictions,
is an advantage for everybody, developer's and maintainers. Not
only Chris Lightfoot. And has always been the
On Jun 3, 2005, at 10:40 AM, Guy Harris wrote:
As happens all too often, patches that add new APIs don't include a
patch to pcap.3.
Either that patch did, or I added it, as those routines *are*
documented in pcap.3.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to
Guy,
Guy Harris wrote:
Loris Degioanni wrote:
When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE
related functions introduced?
November 2004:
https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577
We still don't export them in
Loris Degioanni wrote:
When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE
related functions introduced?
November 2004:
https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577
We still don't export them in WinPcap, and
I don't s
Guy,
Guy Harris wrote:
On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote:
Here is a KB documenting it
http://support.microsoft.com/default.aspx?scid=kb;en-us;94248
That's a bit nastier - not only can't a C runtime file handle (the file
descriptors returned by the UNIX-like _open() call
On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote:
Here is a KB documenting it
http://support.microsoft.com/default.aspx?scid=kb;en-us;94248
That's a bit nastier - not only can't a C runtime file handle (the
file descriptors returned by the UNIX-like _open() call and used by
the UNIX-li
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 02, 2005 2:30 PM
Subject: Re: [tcpdump-workers] pcap_dump_file & CO
On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote:
Trying to understand why the -C tcpdump option doesn&#
On Jun 2, 2005, at 1:35 PM, mcr wrote:
Seems reasonable, but it certainly seems like a Windows.dll silly
to me.
Yes, but, as per my mail, there are arguably other reasons why
pcap_dump_ftell() should exist, namely that applications should have
the idea that a "pcap_dumper_t" is just a
On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote:
Trying to understand why the -C tcpdump option doesn't work under
Windows, I realized that a file pointer created in a dll can only
be used inside that dll. This is a documented Windows limitation.
So where is this documented?
-
This is t
-BEGIN PGP SIGNED MESSAGE-
> "Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
Loris> - pcap_dump_file and the other functions to make file
Loris> pointers explicit don't have any meaning in Windows, because
Loris> any stdio function will fail with those pointers, so
Loris Degioanni wrote:
Trying to understand why the -C tcpdump option doesn't work under
Windows, I realized that a file pointer created in a dll can only be
used inside that dll. This is a documented Windows limitation.
Gak. That sux. Ethereal's capture file library is also done as a dll
on
Trying to understand why the -C tcpdump option doesn't work under
Windows, I realized that a file pointer created in a dll can only be
used inside that dll. This is a documented Windows limitation.
This means that:
- pcap_dump_file and the other functions to make file pointers explicit
don't h
23 matches
Mail list logo
